Help With Better Design

[apollonius2 at gmail.com]

> I've written code that looks a lot like that, and it's
> a perfectly acceptable pattern IMHO.  I don't bother
> with the variables ON and OFF, though, as they add no
> clarity to simply using 'ON' and 'OFF' for the states.
>
> [...]
> The test portion of the code is actually longer than
> the class
> itself :-)
>
> That's usually a good thing!  It means your code is
> concise, and your tests are exhaustive.  (But that
> doesn't mean you can't also refactor your tests.)

I have a habit of falling into the ole' "re-invent the wheel" trap. As
long as I can be thurough without veering too far off course i'm in
good shape.

---------------------------------------------------------------------------------------------------

>
> Better to use newstyle classes:
>   class LightBulb(object):
>
> >     def __init__(self, initial_state):
> >         self.state = initial_state
>
> >     def TurnOn(self):
>
> Pep-08 (naming conventions):
>        def turn_on(self):
>
> >         if self.state == OFF:
> >             self.state = ON
> >         else:
> >             print "The Bulb Is Already ON!"
>
> >     def TurnOff(self):
> >         if self.state == ON:
> >             self.state = OFF
> >         else:
> >             print "The Bulb Is Aleady OFF!"

Thanks for mentioning that as I have never looked at PEP-08 before
(just looked it up) and I bookmarked it for future reference.

> What about:
>
> class LightBulb(object):
>    def __init__(self, state):
>      self.state = state
>
>    def switch(self):
>      self.state = not self.state
>
> (snip)

I never thought about it using a switch.  Steven eluded to it (toggle)
in his re-write of the code. I plan on using that idea.

> > I would like to be able to get a good hold of the concept
>
> state machines ?

Well both state machines and classes (objects). That may be a bit of a
tall order to take on all at once but the concepts seem to be quite
related. I already have a great deal of material on Classes so good to
go there. The state machine idea came from a game tutorial I was
reading and it really sparked my interest.

> > with this example before I try to model a more complex problem. Would
> > someone be willing to give me some feedback on this class and whether
> > I am on the right track or how I might better go about it?
>
> There is a lot to say about OO and state machines. Someone once defined
> the use of OO in simulations as "building an big unpredictable state
> machine from small predictable state machines". As a matter of fact,
> objects are (most of the time) informal state machines (they have state,
> and they have behaviour depending on state). Now there are much more
> formal state machines (google for "FSM" or "finite state machine") -
> which can be implemented in a lot of ways - including the "State" design
> pattern.
>
> Before jumping to implementation, you should probably try to model the
> "more complex problem" with something like UML state diagram (one of the
> few usable things in UML).
>

Thanks. Found some good FSM articles, that should help.