[Haskell-cafe] The Good, the Bad and the GUI

[Wojtek Narczyński]

On 12.08.2014 05:31, ok at 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