4 ms·
It's a contrived example. There is no need to store the "state" of a user if you can infer it from other state. Just define a "deleted" user as a user with a de
by sklivvz1971 11y ago
It's a contrived example. There is no need to store the "state" of a user if you can infer it from other state. Just define a "deleted" user as a user with a deletion date...
Modeling is hard, maybe it should be done more accurately...
- alkonaut 11y agoAnd even if it was required (Say there were 3 states) it's an obvious smell to have a field in a type that is used only in one "state" of the object. The presence of such a field is the most obvious clue that one needs a new class for that state.
- achr2 11y agoPersonally, I would call it a smell to have classes that only extend minor state, especially when this forces immutability into paradigms that do not have immutability as a prime component (.net UI frameworks for example). To me IsActive/Deleted is a property of a User, not a type of user.
- alkonaut 11y agoIn this contrived example, the deletedDate alone is enough to create the required states (Deleted being when there is a deletedDate) without creating any invalid date (Deleted without deleted date or vice versa). In general though, if there were 3 states (active, suspended, deleted) where some states required more data than others, I'd probably make a struct+enum to create the equivalent of the F# type. The user can expose the state while hiding the fact that it has a more complex internal field.
- jameshart 11y agoThat's far from a universal truth. Only US users have a 'social security number' field. Should US users be a different class than German users? Only cars have a 'passenger count' field. Only electric vehicles have a 'battery capacity' field. What type system can accommodate both Teslas and Harley Davidson LiveWire bikes?
- alkonaut 11y agoSocial security, maybe a field can be of a "national identifier id" number? I have an id number but parsing and validating is different from the us version. Since it's a different format and different logic I don't see why another type wouldn't be useful. Passenger number: "0" seems like a valid number that can make sense even for non-passenger cars. I agree it's not black and white, though.