Re: Why encapsulate state pattern......

Mark Nicholls a écrit : 
Bruno Desthuilliers wrote:

Mark Nicholls a écrit :

from GoF the state pattern is to.....
"Allow an object to alter behaviour when it's internal state changes,
the object will appear to change its class"

But my question is, if you want to change it's class (and in fact often
its interface, but you can't), then why not just change it.


BTW, it's the simplest thing to do in some languages:


(snip Python code)


Note that we *do* change class - and behaviour -, without breaking
encapsulation, and without changing the object's identity.



I have to admit this being mildly gobbledygook, just because I'm not
familiar with the syntax,


mostly like executable pseudocode... Python syntax is usually simple stupid.

I think I sort of
understand......environments where you can change your class but not
your identity don't really sit in my head very well,

Then you probably should take time to learn languages like Ruby and Python and their grand-brothers Smalltalk and CLOS. Even if you have no use for them in your day-to-day job, anything that brings you new ways of solving old problems makes you a better programmer.

unless it is
analgous to a class implementing multiple interfaces,

If you mean "interface" as "a set of messages an object understand", undestand that a class is *always* (well, almost...) implementing multiple (implicits) interfaces. Each subset of the whole class interface that is used by a particular client code *is* an (implicit) interface of the class. This is how type inference works BTW.

But I guess you mean Interface "à la Java", ie pure abstract classes used only to fool|satisfy the compiler in a declarative statically typed language. And no, the object *really* changes *class*. Classes are just objects[1] (I mean, in this kind of languages where just everything is an object), and an object keeps a reference to it's class, so it's just a matter of rebinding that reference...

[1] in case you wonder about this, yes, this means that classes are themselves instances of other classes...

and thus you can
change your interface and keep you identity....

Here you change your *class* (then behaviour too) and not your identity. This may lead to interface (in the real meaning, not 'à la Java') change too *if* the classes an object may be bound to during it's life dont expose the same interfaces.

.which is virtually
identical to what I'm suggesting

If the different classes the object uses as states don't implement the same interface, then yes it's pretty close to what you suggested, except for verbosity and loss of identity.

(except that I don't think identity is
actually an issue).


It is, and it's IMHO one of the biggest flaws of your proposition.
.

Relevant Pages

  • Re: Darkroom software Help
    ... Apple's computer operating system OS-X includes the Java ... programing language, compiler, and integration software. ... have an Apple this fall. ... Said that, my system is based on a commercial lab interface, the ...
    (rec.photo.darkroom)
  • Re: object system...
    ... conflict with the actual sun and stars (so, ... Interface too can have some properties defined in terms of third types ... not the language or its target. ... If you ignore overflow exceptions, then necessary, the semantics becomes ...
    (comp.object)
  • Re: Great SWT Program
    ... not sure what the user interface of 2057 will be like, ... GUIs initially seemed to me. ... The clipboard will probably see big changes; ... difficult to program than in some other language. ...
    (comp.lang.java.programmer)
  • Re: Forth and Unix -- history
    ... Forth, as a language, gives you all the building blocks. ... So does FORTRAN, so does C, so does PERL, so does Python. ... to interface to some free library written in whatever language. ...
    (comp.lang.forth)
  • Re: object system...
    ... There's a reason why getters and setters exist. ... interface presumably implemented by the object. ... which need not know much about the language which ... I don't see any need for special features to do delegation. ...
    (comp.object)