2 ms·

I disagree that avoiding ADTs is the solution, it only exacerbates the issue further. When you only have flat records, they often have a lot of data that is or

I disagree that avoiding ADTs is the solution, it only exacerbates the issue further. When you only have flat records, they often have a lot of data that is or isn't set based on the state of the record. For example, a Workflow data structure that doesn't have an ErrorMessage field set when there's been no error. This could be a data structure with an FailedWorkflow and SuccessfulWorkflow, and the ErrorMessage only on the FailedWorkflow. Helper functions that receive a lot of state aren't ugly, they are pure. Pure code is easily tested. It is easy to reason about and reuse, because it's clear what the expected inputs and outputs are. http://deliberate-software.com/anemic-domain-model/ http://deliberate-software.com/anemic-domain-model/

jstimpfle 8y ago
Yes, deliberate denormalization is not a solution. If you need an ADT, use an ADT. However, you can put all the case-by-case data in separate non-ADT structures. Then think hard if you really need to "unify" them and only if so make an ADT that simply links to the other structures and contains no additional data. Works well for me. (This is not a hard rule. For example, layouts for disk serialization might be better done as a single union with a discriminator field. In this case we're not optimizing for code but for disk accesses).