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. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
