I've got an class that is really a flattened repre...

# announcements

[Wesley Acheson]

I've got an class that is really a flattened representation of several different types of field. (its a document in nosql terms) that has lots of fields. (I think close to 100) and I'm building it up using a transformer, so on a field by field basis.

I'm currently modeling as class where all fields are mutable, nullable, defaulting to null. However I know that certain values will always be eventually specified.

Is that the right way to model this, Or should I have a data class with constructor parameters for everything? I feel that using a hundred myValue.copy(fieldName = fieldValue) may be a bad way to deal with it. Or I guess I could implement the builder pattern but that feels like an extra step to go wrong/maintain. Though I guess the advantage of the builder pattern Is that I can verify that the fields that aren't supposed to be null aren't null.

What do you all think?#

[CLOVIS]

Do you know about lateinit var, and can you use it?

[Wesley Acheson]

Yeah I have used that in the past but tried to avoid it. I was kind of hoping that there may be built in support for builders.

lateinit will throw an exception only on read right? So as long as I don't read the value it will not throw.

[CLOVIS]

Exactly

[CLOVIS]

When do you want to check your values? When the object is instantiated, or when the values are queried?

[Wesley Acheson]

I'll think thanks @CLOVIS