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? -- http://mail.python.org/mailman/listinfo/python-list
