[Tutor] domain logic and avoiding setters and setters.

[Alan G]

OK, I'll take a chance because as you say I don't know the
details of what you are building. And if its a Framework
for persistence, or an IDE for building persistence then
get/set may be your best bet - after all that's why Java
Beans have them so that Java IDEs can manipulate object
properties at design time.

But...

> Application (Output)
>         Presenter (renders HTML or other UI)
>                Persisted object/default generator

So the persisted object returns a string representation
of its state (maybe as a csv?) which the Presenter parses
and adds tags as needed?

>        Editor (what we are looking at, is specific to the persisted
>                object, holds the rules and updates/creates
>                persisted object)

Not sure about this one? Why is 'editing' not a function of the
persisted object? It might be valid if its not a relevant business
function but if the object inherits a persistent mixin it should
be an attribute of the mixin which object inherits.

The rules should either be objects in their own right ot methods
of the objects attributes or methods of the object - after all
thats what objects are for: to hold their own business rules.
If you really mean the storage rules (database constraints),
then that might be a valid exception, but at that point the
persistence mechanism is operating at the raw data level
- ie the attributes of the object not the object itself. How
do we get from the object to the data? By having a csv, or tlv
or similar method on ll persistent objects. The tlv method of
the object returns a tlv representation of the current object
then the tlv of the superclass. This is standard object serialisation
type upward delegation through an inheriance lattice.

> Presenter and Editor will have some knowledge of the persisted 
> object.

By doing so they cease to be either generic or reusable.
They should communicate with the object via a standard protocol.
They should not need to be aware of individual attributes they
should only need the total state of the object. Editing implies
changes of attribute value but those should only be made through
the object's own protocol, even if that implies instantiating the
object, calling the relevant operation and then persisting it
again. Only where there are proven performamce issues should direct
attribute access at the data level even be considered.

> that may be in between). So conceptually the domain object is just
> split into three classes and Demeter <only talk to your friends> is
> observed everywhere else, at least as far as I understand it's
> principles.

The question is why should it be broken here? The Framework/IDE 
scenario
is the only one where it may be valid to beak demeter (and even then 
only
rarely), but very few real world scenarios need to go down that route.

But, it does rely totally on your domain and issues such as 
performance.
Theoretical principles are fine until they hit the real world then 
they
have to bend or be broken. But we should always try to follow them 
first,
bend them next and break them as a ;ast resort - we will suffer later
if we do otherwise.

Good luck,

Alan G.