En Tue, 19 Jun 2007 22:34:27 -0300, <[EMAIL PROTECTED]> escribió:
> I have been working on a little project today to help me better
> understand classes in Python (I really like Python). I am a self
> taught programmer and consider myself to fall in the "beginner"
> category for sure. It was initially sparked by reading about "state
> machines". This was my attempt at it however I feel it is not quite
> where it should be:
That's rather good as it is!
> ON = "ON"
> OFF = "OFF"
>
> class LightBulb:
> def __init__(self, initial_state):
> self.state = initial_state
>
> def TurnOn(self):
> if self.state == OFF:
> self.state = ON
> else:
> print "The Bulb Is Already ON!"
One could argue here: is it an error to attempt to turn the light on
again, if it is already on?
If yes: raising an exception is the usual way to report error conditions
(let the caller handle it, if he cares enough)
If not: why to check the current state? Just set the new state as ON,
whatever was the prior state.
The same for TurnOff. (BTW, the reccomended style is to use lower_case
(best) or mixedCase for method names: turn_on or turnOn)
> def TurnOff(self):
> if self.state == ON:
> self.state = OFF
> else:
> print "The Bulb Is Aleady OFF!"
>
> if __name__== "__main__":
> light = LightBulb(OFF)
> simulation_running = True
> while simulation_running:
> print "The light is", light.state
> print ""
> print "Please choose an action:"
> print ""
> print "[1] Turn Light On"
> print "[2] Turn Light Off"
> print "[3] Exit Simulation"
> print ""
> u_choice = raw_input("Please Enter Your Choice: ")
> if u_choice == '1':
> light.TurnOn()
> if u_choice == '2':
> light.TurnOff()
> elif u_choice == '3':
> break
> else:
> continue
>
> The test portion of the code is actually longer than the class
> itself :-)
That's often the case!
> I would like to be able to get a good hold of the concept
> 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?
The example is fine. You could move on from "interactive testing" (your
"demo" program, where a human runs some code, more-or-less at random, sees
the results and judges by himself if it is "OK" or "wrong") into
"automated unit testing": an automated sequence of tests, each with its
input and expected output, that can be executed automatically and without
any human intervention.
There is a framework for writing those (see the unittest module), but you
can start just by using the assert statement:
light = LightBulb(OFF)
assert light.state == OFF # ensure that it gets initialized correctly
light.TurnOn()
assert light.state == ON # ensure that TurnOn actually does as intended
light.TurnOff()
assert light.state == OFF
light.TurnOff()
assert light.state == OFF # an attempt to turn it off again should leave
it off
light.TurnOn()
light.TurnOn() # an attempt to turn it on again
assert light.state == ON
# some more tests
light = LightBulb(ON)
assert light.state == ON # should test both initial states
light = LightBulb(0) # what should happen here?
light.TurnOn()
assert light.state == ON # oops!
light.TurnOff()
assert light.state == OFF # oops!
This has many advantages: you can write the tests carefully once and run
many times later, and detect breakages; you can't take a "likely" answer
for a "true" answer; etc.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
