Accessors in Python (getters and setters)

[mystilleef]

Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Gerhard Fiedler wrote:
> >
> >>On 2006-07-15 06:55:14, mystilleef wrote:
> >>
> >>
> >>>In very well designed systems, the state of an object should only be
> >>>changed by the object.
> >>
> >>IMO that's not quite true. Ultimately, the state always gets changed by
> >>something else (user interaction, physical events); very few objects are
> >>completely self-contained in their behavior.
> >>
> > Then in those cases the system becomes a victim of high coupling.
>
> Time to burn your book and face reality. ObjA sends message Msg1 to
> ObjB. Part of the associated behaviour is that in responce to Msg1, objB
> changes it's own state. Practical result : ObjB's state has been changed
> by ObjA. Practical question : how do you hope to avoid this "hi
> coupling" (lol), apart from making all your objects totally autistic ?
>

Are you serious? Well, you design an object that serves as a mediator.
All objects can then only interact with themselves and the mediator
only. Via signals, objects learn to automatically adjust their states
and respond to events. This is just one of several methods you can
dramatically reduce coupling. I'm sure glad I didn't burn my book.

> >>In most systems (and you possibly have written some of them) are objects
> >>whose state gets changed by other objects -- possibly through the
> >>intermediation of setter methods that do nothing else but set the state.
> >>There's no conceptual difference between directly setting the state or
> >>calling a setter function that does nothing else but directly setting the
> >>state -- except for one unnecessary level of indirection in the latter.
> >>
> >
> >
> > It depends. If certain conditions need to be met before changing the
> > state of an object, then arbitrarily changing it can be dangerous.
>
> Does this imply a 'method call' *syntax* ?

That's language dependent.

>Given the existence of
> "computed attributes" (ie: support for 'attribute access' *syntax* with
> hidden accessors) and the possibility to redefine implementation (from
> default attribute r/w access to computed/controlled) without touching
> the interface, why advocate the *systematic* use of computed attributes
> when it's just duplicating the default behaviour ?
>

I'm not advocating anything. I'm just stating the use case for
accessors and the wisdom behind them. My qualm with implicit accessors
remains the name issue.

>
> >
> >>>For example, a third party randomly changing is_active, (which Python
> >>>lets you do freely and easily) from False to True may crash your GUI.
> >>>And I'm not making this up. Things like this do really happen depending
> >>>on the whackyness of your toolkit.
> >>
> >>That's quite true, but a setter that does nothing but change is_active
> >>doesn't prevent this. If there is logic necessary to prevent state changes
> >>in certain situations, this should be implemented. But whether you then
> >>call this a part of the "behavior" (looking at the implementation as being
> >>a setter method) or a part of the "state" (looking at the implementation as
> >>being an added feature of the attribute) doesn't really make an objective
> >>difference.
> >>
> >
> >
> > Of course using setters for the sake of just using them is pointless.
>
> Indeed.
>
> > The reason to use them is if pre-conditions or post-conditions need to
> > be met. Or to control access to an objects states.
>
> Then why advocate *systematic* use of them ?
>
> (snip)

I never advocated anything. On the contrary, I asked a query?

> >
> > State - behavior is not something I made up, so it isn't subjective.
>
> The words (and the concept they describe) are not. Interpretation of
> what is state and what is behaviour is subjective.
>
> > It
> > is a common term used in OO literature. In fact, the only reason I used
> > it is because I thought is was common knowledge.
>
> It is.
>
> > And behaviors are not
> > just necessarily getters/setters, they are methods of objects.
>
> Behaviour is how a given object reacts to a given message. *Nothing* in
> this implies the notions of attributes or methods. Attributes and
> methods are implementation details of the concepts of state and
> behaviour, and - while this is a common implementation of OO concepts -
>   the choice to use non-callable attributes as representing the state
> and callable ones as representing behaviour is totally
> implementation-dependant.
>

I agree. And I already told you I think in terms of state and behavior
and not language dependent semantics.