I appreciate your input. You are correct. I read a bunch of LoD stuff
Northeastern website. It codified a bunch of things that I had been
working through.
But what you are not seeing (I must be terrible at this, always hard
to tell how much code to post) is this chunk of code represents an
idea about ways to hang business rules in an inheritable way onto a
persisted (sqlobject) object. It is really in the model. This is a
sketch of what I am trying to accomplish.
Application (Output)
Presenter (renders HTML or other UI)
Persisted object/default generator
Editor (what we are looking at, is specific to the persisted
object, holds the rules and updates/creates persisted object)
Application (Input)
Presenter and Editor will have some knowledge of the persisted object.
They will directly access attributes in the persisted object. They
will not directly unveil attributes to the application (or any layers
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.
On 7/12/05, Alan G <[EMAIL PROTECTED]> wrote:
> I think you are missing the point a wee bit.
>
> The object should not allow you to access its internal data.
>
> You should not *need* to access its internal data.
>
> The object has responsibilities in the form of behaviours.
> The internal data is only there to support those behaviours,
> it should be of no interest to external objects, therefore
> you do not need setters and getters. Its not the setXXX getXXX
> thing thats wromg its the very idea that users of the object
> would want to access the internal data that is wrong.
>
> In the words of Peter Coad, "Objects do it to themselves"
>
> Now in some applications you do need the internal values,
> but usually its as a group. For example an Address class
> might have a method to return the full address content,
> but rather than provide individuual set/get methods per
> field it would return the whole address as a string or
> a tuple.(Note that both of these are immutable types!)
>
> In some cases you may actually choose to expose one
> particular attribute, in which case a get/set pair for that
> one attribute is OK - they represent a genuine responsibility
> of the class. (Making it a property might be better still...)
> Its providing get/set pairs for *every attribute* that breaks
> good OOP practice.
>
> PS. For a more formal description of the above principle
> look up "The Law of Demeter" on Google.
>
> HTH,
>
> Alan G
> Author of the Learn to Program web tutor
> http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
