Accessors in Python (getters and setters)

[mystilleef]

Bruno Desthuilliers wrote:
> mystilleef wrote:
> > 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?
>
> Deadly serious. But I'm afraid you're still missing the point.
>
> > 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.
>
> signal -> message -> method call -> change state.
>
> Spell it how you like, add as many indirection levels you want, it still
> boils down to the fact that *something* triggers the state change.
>

Riiiiight!

> > This is just one of several methods you can
> > dramatically reduce coupling.
>
> It's just one of several methods that dramatically increases complexity,
> without changing anything to the fact that in the end, *practically*,
> some object ObjA changes its state as a response to a message sent by ObjB.
>

Say that to game/simulation developers.

> > I'm sure glad I didn't burn my book.
>
> No comment.
>
> >
> >>>>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.
>
> cf below on this.
>
> > I'm just stating the use case for
> > accessors and the wisdom behind them. My qualm with implicit accessors
> > remains the name issue.
>
> The "name issue" is *your* problem. And AFAICT, it's a "problem" because
> you refuse to free your mind from a "what's in the book" mindset.
>

What book are we talking about?

> >
> >>>>>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.
>
> You advocated
> """
> 1). Make all attributes of a class private/protected .
> 2). If a "non-callable" attribute is going to be used outside a class,
> think about making it a property and name the property well, because
> you never know...
> """
>

You use accessors when you need to control access to a data attribute.
That's not advocacy, that's common sense.

> >
> >>>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.
>
> Then why do you advise "(making) all attributes of a class
> private/protected" and systematically using properties ?
>

Because you don't want third parties illegimately tampering with an
object's internal data and thus crashing your system?