Coming from Java where nullability is sort of a free for all, I wonder how do you resolve this problem. I have a

User

data class which has a

type

field. The type can be either

REGULAR

or

ADMIN

. When it is of type

ADMIN

the user will always have a not null

companyId

but when it is a

REGULAR

user the

companyId

will always be null. Therefore the

companyId

now has to be nullable and I am forced to handle it even in this case:

val user = db.getUser(id)
if (user.type == ADMIN) {
  // user.companyId is definitely NOT NULL here but the compiler obviously has no idea
} else {
  // user is a REGULAR user so the companyId is null

The only way around this is to have two different classes: an

AdminUser

and

RegularUser

that will reflect the reality more closely. Is there a better way? In Java the compiler does not care and I get no warnings.

Different classes is probably the best way. Having flags that determine the presence of other fields is a code smell.

Having a user type is a code smell?

Instead of having "type" field consider having different implementations of user. Thats what Henning Hoefer states i guess.

You have to encode it in the types somehow. If your objection to

AdminUser

and

RegularUser

is duplication then maybe you should just have a

val User.adminData: AdminData?

that exposes these non null values

I am just wondering how would you do it because it seems like a very common use case. Would you really map one db table to two different classes?

Could you have your “type” be a sealed class hierarchy where the

Admin

type has a non-null companyId.

@poohbar It is pretty common. In JPA it's called "Table per class hierarchy": https://www.baeldung.com/hibernate-inheritance#single-table

I see.. yeah this is what I am doing. Most of my tables have a

type

column which determines their place in the "hierarchy". Except I didn't really model the hierarchy in my data classes.

How is your data mapped in the Database? A

User

-Table and another table

Admin

with a foreign key to

User

plus the

companyId

?

no.. there is just one table called

user

if you’re using hibernate there’s a mapping strategy for that https://www.baeldung.com/hibernate-inheritance #3 One table per class hierarchy

jOOQ forever!

then you’re on your own...