On 12.08.2014 05:31, ok@cs.otago.ac.nz wrote:
If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification. You seem to be referring to the "incompletely initialised object" anti-pattern. The books I have about concurrency in Java/on the JVM strongly recommend making Java objects immutable when you can.
Even in Visual Basic, if an object is "constructed" via a lengthy sequence of steps, it is good design to distinguish between two different things": a fully constructed Foo object and a FooBuilder object. Sometimes they need to be the same object, but there really do need to be two *interfaces*. Once past the construction phase, you want to KNOW that the object is fully constructed, and there are things the constructor might do that you DON'T want other objects to do.
Take a VAT Invoice as an example. You will have: Invoice, InvoiceBuilder, InvoiceLineItem, InvoiceLineItemBuilder, InvoiceCustomer, InvoiceCustomerBuilder, InvoiceSummary, (no Builder, as this is calculated) (many, many more classes in a realistic system) Now, where the rather complex validation belongs? Optional / mandatory requirements, lengths, ranges, regexps, control sums, field interdependencies, autocompletes, server sent notifications? Where to put all of this? To regular classes, to builder classes, or to both? -- Wojtek