On Sat, Feb 9, 2008 at 9:46 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> As I mentioned in an earlier mail it tends to oscillate in practice.
> You start off looking at the problem to identify the basic classes.
> Then you pick one or two and start designing those in detail and
> that identifi
On Wed, Feb 20, 2008 at 7:53 PM, Alan Gauld <[EMAIL PROTECTED]> wrote:
> "Michael Langford" <[EMAIL PROTECTED]> wrote
>
> > I'm firmly with Kent here: OO programming is not about simulation.
>
> Wooah!
> I'm partly on board here and do agree the noun/verb thing is
> a gross simplification. But
"Michael Langford" <[EMAIL PROTECTED]> wrote
> I'm firmly with Kent here: OO programming is not about simulation.
Wooah!
I'm partly on board here and do agree the noun/verb thing is
a gross simplification. But it does work and is how probably
the majority of OOP programmers started out - in the 8
I'm firmly with Kent here: OO programming is not about simulation. You
are not modeling real world items. You are making code easier to
maintain and making parts of code that have to do with one another be
near one another.
If you spend all your time trying to make your objects into real world
thi
Tiger12506 wrote:
> I like things to be explicit, and don't care for the level of
> abstraction common in MVC. I know it seems naive, but I like to be able to
> model object designs after tangible things, and to me, a View does not know
> how to keep a state or execute methods because it does n
"Tiger12506" <[EMAIL PROTECTED]> wrote
> up. I like things to be explicit, and don't care for the level of
> abstraction common in MVC. I know it seems naive, but I like to be
> able to
> model object designs after tangible things, and to me, a View does
> not know
> how to keep a state or execu
> Now I'm curious.
>
> MVC is one of the oldest, best established and well proven design
> patterns going. It first appeared in Smalltalk in the late 1970's and
> has been copied in almost every GUI and Web framework ever since.
> I've used it on virtually(*) every GUI I've ever built(**) to the
>
"Tiger12506" <[EMAIL PROTECTED]> wrote
> Ah yes... I don't like the Model-View-Controller architecture. That
> the
> major reason why I dislike most information available on C++. This
> is a
> personal issue though. The Model-View-Controller is a very common
> thing, and
> everyone but me would
> Hmm. Not to me. The second version couples the game state with the
> display. I would rather have
True...
> This is an example of Model-View-Controller architecture (google it).
> Notice that the Game and Display are now reusable (maybe there are both
> GUI and text interfaces to the game, f
Tiger12506 wrote:
> vg = VideoGame()
> howmany = rand.randint(0,100)
> for i in range(howmany):
> vg.buttonpush()
> print vg.score#Tear open the case (hope you have a screwdriver)
>
> OR
>
> class VideoGame():
> def __init__(self):
> self.score = 0
> def updatedisp():
> pr
Alan Gauld wrote:
> This is fine and dandy but what if we want to find out the
> current value of a.value without calling inc?
> Thats where hetter/setter/direct access comes into the
> picture.
> In Java and some other languages the idiomatic thing
> to do is provide methods prefixed with get/s
To further document some points.
This comes from PEP 8 (http://www.python.org/dev/peps/pep-0008/)
For those who need "authority" :
Author: Guido van Rossum , Barry Warsaw
"""
With this in mind, here are the Pythonic guidelines:
- Public attributes should have no leading underscores.
Tiger12506 wrote:
>>> This is all fine and dandy, but the video game is pretty worthless unless
>>> it
>>> can show us what the score is. There are two ways to go about this. A)
>>> Give
>>> the video game a display which it updates, or B) Tear open the case of
>>> the
>>> video game and look at
>> This is all fine and dandy, but the video game is pretty worthless unless
>> it
>> can show us what the score is. There are two ways to go about this. A)
>> Give
>> the video game a display which it updates, or B) Tear open the case of
>> the
>> video game and look at the actual gears that in
On Feb 12, 2008 7:19 AM, Ricardo Aráoz <[EMAIL PROTECTED]> wrote:
>
> Did we think about REUSABILITY? What if in some other application I want
> to USE the score, not just display it? What if I want to display it in a
> different form (multiplying it by 100)? Then you are back to our
> original opt
Tiger12506 wrote:
> This is all fine and dandy, but the video game is pretty worthless unless it
> can show us what the score is. There are two ways to go about this. A) Give
> the video game a display which it updates, or B) Tear open the case of the
> video game and look at the actual gears t
Tiger12506 wrote:
> This is all fine and dandy, but the video game is pretty worthless unless it
> can show us what the score is. There are two ways to go about this. A) Give
> the video game a display which it updates, or B) Tear open the case of the
> video game and look at the actual gears t
"Tiger12506" <[EMAIL PROTECTED]> wrote
> Well, I don't know if this whole email was of use, but it makes the
> crux of
> the argument make sense to me.
I thought it was pretty clear.
And it highlights that the choices are like anything else in
the world of engineering - a compromise. And the be
> "bhaaluu" <[EMAIL PROTECTED]> wrote
>
>> States, getters-setters, direct access...
>> I'm still in toilet-training here/ 8^D
>> Can you provide some simple examples that
>> illustrate exactly what and why there is any
>> contention at all?
One clear example I can think of that shows the view
"bhaaluu" <[EMAIL PROTECTED]> wrote
> States, getters-setters, direct access...
> I'm still in toilet-training here/ 8^D
> Can you provide some simple examples that
> illustrate exactly what and why there is any
> contention at all?
I'll try.
State is just a bit of jargon to describe the com
On Feb 11, 2008 3:49 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> I think we are in general agreement, albeit with different levels of
> trust/toleration of the technique. Direct access is preferred to
> getter/setter methods but is in turn less desirable that higher
> level methods where they exi
"Kent Johnson" <[EMAIL PROTECTED]> wrote
>> The secondary reason is that a class author should be free
>> to change the internal data of a class provided he doesn't change
>> the message interface, but allowing direct access greatly increases
>> the risk that a change will break some users code. P
Alan Gauld wrote:
> Over-use of direct access tends, in my experience, to lead to
> the temptation to move code that should be in the class (or a
> subclass) into client code. And it is avoidance of that temptation
> that is my main reason for providing a values() or state() type
> method, rather
"Kent Johnson" <[EMAIL PROTECTED]> wrote
> Alan doesn't like direct attribute access *or* getters and setters,
> IIUC. He wants all access to the attributes of a class instance to
> be
> through higher-level methods.
I'd moderate that slightly.
I really, really, don't like getters/setters. So, i
Dave Kuhlman wrote:
> Here is something relevant to this argument, although I'm not sure
> that I agree with it:
>
> "Getters and setters are evil. Evil, evil, I say! Python objects
> are not Java beans. Do not write getters and setters. This is
> what the 'property' built-in is for.
On Sat, Feb 09, 2008 at 08:42:04PM -0500, Kent Johnson wrote:
> Alan Gauld wrote:
>
> >> def values(self):
> >> return (self.name, self.wealth, self.strenth)
> >>
> >> Or get rid of values() entirely and just refer to the attributes
> >
> > Nope, I don't like that as much since it encourage
Alan Gauld wrote:
>> def values(self):
>> return (self.name, self.wealth, self.strenth)
>>
>> Or get rid of values() entirely and just refer to the attributes
>
> Nope, I don't like that as much since it encourages direct
> access.
Maybe we just need to agree to disagree here. I don't see
"Kent Johnson" <[EMAIL PROTECTED]> wrote
>> e = Explorer()
>>
>> e.describe(withText=True) # gets the long version
>>
>> or
>>
>> print """
>> You are an explorer whose name is %s,
>> You have wealth of %s and strength of %s
>> """ % e.describe() # uses tuple result
>
> Um, yuck. A functio
Alan Gauld wrote:
> class Explorer(object):
> fmtStr = """
> My name is %s
> and I have wealth of $%s and
> strength of %s"""
>
> # other code here
>
> def describe(withText=False)
> values = (self.name, self.wealth, self.strenth)
> if not withText:
>
"bhaaluu" <[EMAIL PROTECTED]> wrote
> When you're designing a program, how do you go about dealing
> with text descriptions, like the descriptions for a room? Here is an
> example of a room description:
>
> THIS IS THE AUDIENCE CHAMBER
> THERE IS A WINDOW TO THE WEST. BY LOOKING TO THE RIGHT
> THR
> ..., I'd like to have the finished program
> be identical to the procedural program as far as I/O goes.
You could do it but it would be easier to change it a little
because the original games prompts etc betray its internal
structure. You can just get the objects to return their attributes
an
bhaaluu wrote:
> When you're designing a program, how do you go about dealing
> with text descriptions, like the descriptions for a room? Here is an
> example of a room description:
>
> THIS IS THE AUDIENCE CHAMBER
> THERE IS A WINDOW TO THE WEST. BY LOOKING TO THE RIGHT
> THROUGH IT YOU CAN SEE
On Feb 9, 2008 8:46 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
> "bhaaluu" <[EMAIL PROTECTED]> wrote
>
Some more thoughts on designing here.
You said I can use the procedural program as a program "requirement"
because it defines I/O. Even though the OOP program will have the
data and functions in
"bhaaluu" <[EMAIL PROTECTED]> wrote
> the second chapter deals with a Blackjack game. One thing I noticed
> (and remember, this is a Noob's viewpoint): The classes seemed to be
> designed from small to large, rather than from large to small.
As I mentioned in an earlier mail it tends to oscillate
On Feb 9, 2008 4:09 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> "Tiger12506" <[EMAIL PROTECTED]> wrote
>
> > Are some simple examples off the top of my head. It's not difficult
> > to model
> > real-life things with classes, but ...
>
> This is a good point, it is excellent practice for thinking
"Tiger12506" <[EMAIL PROTECTED]> wrote
> Are some simple examples off the top of my head. It's not difficult
> to model
> real-life things with classes, but ...
This is a good point, it is excellent practice for thinking
about the responsibilities of objects
> ...it is much more difficult to m
"bhaaluu" <[EMAIL PROTECTED]> wrote
There have been lots of comments about this already but
I'm deliberately jumping in at this level because I want
to pick up a few general points...
> class Explorer(object):
>"""player"""
>def __init__(self,name):
>"""initilaization method"""
>
> There is nothing like growing a program to the point where you don't
> know how it works or how to change it to make you appreciate good design
Amen. I was recently fighting with an example of a multi-client, simple
server that I wanted to translate into assembly. Not only was the code
unreada
> This is something that one can only gain from experience?
> I really had to struggle to get the Light class to work at all.
> I have no idea how many times I started over. But I do feel
> that I am starting to learn some of this stuff.
This surprises me... I guess it does take experience. What i
bhaaluu wrote:
> On Feb 8, 2008 4:46 PM, Kent Johnson <[EMAIL PROTECTED]> wrote:
>> "Refactoring is the process of changing a software system in such a way
>> that it does not alter the external behavior of the code yet improves
>> its internal structure." -- Martin Fowler in Refactoring
> This is
On Feb 8, 2008 4:46 PM, Kent Johnson <[EMAIL PROTECTED]> wrote:
> bhaaluu wrote:
>
> > It also cleaned up main(), and put everything in well defined packages
> > at the top of the program.
>
> Yes, good OOD puts things into cohesive, comprehensible packages.
>
> > I can see do difference in "game p
bhaaluu wrote:
> It also cleaned up main(), and put everything in well defined packages
> at the top of the program.
Yes, good OOD puts things into cohesive, comprehensible packages.
> I can see do difference in "game play". 8^D
And that's a good thing, right?
"Refactoring is the process of ch
On Feb 8, 2008 3:24 PM, Kent Johnson <[EMAIL PROTECTED]> wrote:
>
> and change the loop from
>while True:
> to
>while explr.alive:
>
> This would give you an Explorer class that actually does something useful.
>
> Kent
>
It also cleaned up main(), and put everything in well defined pa
bhaaluu wrote:
> class Explorer(object):
> """player"""
> def __init__(self,name):
> """initilaization method"""
> self.__name = name
> self.strength = 20
> self.wealth = 60
>
> def get_name(self):
> return self.__name
There is no need for get_
On Feb 7, 2008 9:40 PM, Tiger12506 <[EMAIL PROTECTED]> wrote:
> There's a couple of errors in here that no one has addressed yet because the
> question was geared towards programming style... So now I will address them.
> Or undress them, I suppose. ;-)
I didn't make much progress until I started
Alan Gauld wrote:
> Unit tests and TDD is not a design technique per se.
> It is definitely not a technique for designing OOP programs
> its a programming technique that makes code more reliable
> (whether OOP or not).
>
> Where it does help in design is by focussing attention
> on how a class (o
"bhaaluu" <[EMAIL PROTECTED]> wrote
> PyUnit:
> It really doesn't seem to be an "absolute beginner" technique.
Unit tests and TDD is not a design technique per se.
It is definitely not a technique for designing OOP programs
its a programming technique that makes code more reliable
(whether OOP or
There's a couple of errors in here that no one has addressed yet because the
question was geared towards programming style... So now I will address them.
Or undress them, I suppose. ;-)
> #!/user/bin/python
> """
>>From the testing laboratory of:
> b h a a l u u at g m a i l dot c o m
> 2008-02-
On Feb 7, 2008 6:47 PM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> "Alan Gauld" <[EMAIL PROTECTED]> wrote
>
> >> What is the equivalent of JUnit in Python?
> >
> > I think the nearest equivalent is
> >
>
> Oops, I was going top say PyUnit then remembered the name
> had changed but forgot to check ou
"Alan Gauld" <[EMAIL PROTECTED]> wrote
>> What is the equivalent of JUnit in Python?
>
> I think the nearest equivalent is
>
Oops, I was going top say PyUnit then remembered the name
had changed but forgot to check out the latest incarnation.
Fortyunately others have done the work for me.
P
On Feb 7, 2008 4:58 PM, Eric Brunson <[EMAIL PROTECTED]> wrote:
> bhaaluu wrote:
> > What is the equivalent of JUnit in Python? The article says that JUnit is
> > used for unit tests, or you can write your own. Since I don't have a clue,
> > writing my own is probably out the question. Also I'm not
"bhaaluu" <[EMAIL PROTECTED]> wrote
> What is the equivalent of JUnit in Python?
I think the nearest equivalent is
> writing my own is probably out the question. Also I'm not familiar
> with
> Java, and am just learning Python OOP, so I'm not getting much out
> of that one. Sorry. Absolute Beg
bhaaluu wrote:
> What is the equivalent of JUnit in Python?
The unittest module is based on JUnit.
http://docs.python.org/lib/module-unittest.html
Here is a simple introduction to the capabilities of unittest. It
doesn't do much to motivate the examples though:
http://www.oreillynet.com/onlamp/
bhaaluu wrote:
> What is the equivalent of JUnit in Python? The article says that JUnit is
> used for unit tests, or you can write your own. Since I don't have a clue,
> writing my own is probably out the question. Also I'm not familiar with
> Java, and am just learning Python OOP, so I'm not getti
On Feb 7, 2008 4:07 PM, Kent Johnson <[EMAIL PROTECTED]> wrote:
> bhaaluu wrote:
>
> > The TDD method is the method used in my tutorial:
> > Python Programming for the Absolute Beginner 2E. Michael Dawson. 2006.
> > Dawson uses a very simple Tamagotchi example called Critter Caretaker
> > to introd
bhaaluu wrote:
> The TDD method is the method used in my tutorial:
> Python Programming for the Absolute Beginner 2E. Michael Dawson. 2006.
> Dawson uses a very simple Tamagotchi example called Critter Caretaker
> to introduce the mechanics of POOP. However, perhaps he is using
> the TDD method of
Also beware the difference between reassigning and extending:
class F:
a = 3
b = []
def __init__(self, a, b):
self.a = a
self.b.append(b)
def show(self):
print self.a, self.b
f1=F(1,2)
f2=F(3,4)
f1.show() # 1 [2, 4]
f2.show() # 3 [2, 4]
--
Bob Gailer
919-636-4239 Chapel Hill
> Sorry, my bad - this was my me, but I forgot to hit "Reply All".
My me? I think I meant to type "my message".
--
www.fsrtechnologies.com
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
bhaaluu wrote:
> Best practice?
Use class attributes when you actually want a shared attribute, for
example for constants with class scope, or as defaults when instance
attributes may not be assigned. Class attributes can be redefined by
subclasses which makes them useful as a way to configure
I was asked:
Here's a situation I often encounter, and I was wondering what the
"best practice" is. I've generally initialized my classes' attributes
this same way:
> class TestClass1(object):
> """ please give me a better name"""
> def __init__(self):
> """please document me""
Greetings,
I've read both Kent's and Alan's approaches to designing a POOP,
and am intrigued with the possibilities of the noun/verb/adjective
technique, but am also sympathetic to the TDD method as well
because it is how I've always programmed. I have noted Alan's
comments on the limitations of T
Alan Gauld wrote:
> "Kent Johnson" <[EMAIL PROTECTED]> wrote
>> The writings of Robert C Martin have taught me a lot about good
>> design
>> and agile development. They don't all apply to Python
>
> Martin is very good on Agile, I'm less impressed with his OO writing,
> largely because he does te
On Feb 6, 2008 8:15 PM, Kent Johnson <[EMAIL PROTECTED]> wrote:
>
> Design a little, code a little, repeat...
> http://personalpages.tds.net/~kent37/stories/3.html
>
>
> You can discover many useful design techniques by applying DRY. More here:
> http://personalpages.tds.net/~kent37/s
"Kent Johnson" <[EMAIL PROTECTED]> wrote
> Let me say that I don't mean any disrespect for Alan or his
> approach, I
> just have a different point of view.
Heh, heh! I was waiting for someone to post a message like this.
I'll respond by saying the noun/verb thing is not actually the
method I wou
bhaaluu wrote:
> How do you design POOP? What are the guidelines you keep in mind
> to design "good" POOP? Can an absolute beginner learn to design POOP?
I have mostly stayed out of this thread for lack of time and because
Alan is doing a great job, but I think I will chime in a bit because
this
"bhaaluu" <[EMAIL PROTECTED]> wrote
Let me preface this message by saying that I've never written
a TAG before - either procedurally nor using OOP. so I don't
know if the following approach is a good way to go or not.
However it's where I feel things moving...
> I have a tendancy to think abo
On Feb 6, 2008 12:06 PM, Alan Gauld <[EMAIL PROTECTED]> wrote:
> "bhaaluu" <[EMAIL PROTECTED]> wrote
>
> > Here is my description, in plain English.
> >
> > Text Adventure Game Requirements:
> > 1. The Explorer enters her name at a prompt.
> > 2. Other things are initialized at this point.
> > 3. T
Thank you Alan.
This helps tremendously! I had gone to your OOP tutorial and read it
over (again) and the closest thing I could find on that page was
the Bank Account example that had a list of things a bank account
might be expected to do. So away I went, making a list.
The problems with that ap
"bhaaluu" <[EMAIL PROTECTED]> wrote
> Here is my description, in plain English.
>
> Text Adventure Game Requirements:
> 1. The Explorer enters her name at a prompt.
> 2. Other things are initialized at this point.
> 3. The layout of the Castle is defined.
> 4. Treasure is placed in rooms in the
On Feb 5, 2008 3:02 PM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> Describe the problem in plain English text(or whatever you
> language is!).
> --
> Alan Gauld
> Author of the Learn to Program web site
> http://www.freenetpages.co.uk/hp/alan.gauld
>
Here is my description, in plain English.
Text
On Wed, Feb 06, 2008 at 08:58:09AM -, Alan Gauld wrote:
> Thus always base inheriotance on common mbehaviour not on
> common data.
>
> I hope that makes it clearer.
Thanks Alan, it's clear now. And now I know that this is not one of
the mistakes I am making ;)
Tiago Saboga.
_
On Feb 5, 2008 3:02 PM, Alan Gauld <[EMAIL PROTECTED]> wrote:
>
> One of the earliest ways of doing this has now fallen sonewhat
> out of favour but in practie I find it works quite well for beginners
> is:
>
> Describe the problem in plain English text(or whatever you
> language is!). Underline th
"Tiago Saboga" <[EMAIL PROTECTED]> wrote
>> sub types of an abstract superclass. Do NOT use data
>> attributes for this, always base inheritance heirarchies
>> on behaviour.
>
> Could you please elaborate on this last sentence? I don't understand
> what you mean, and I feel I may be on this track.
On Tue, Feb 05, 2008 at 08:02:19PM -, Alan Gauld wrote:
> "bhaaluu" <[EMAIL PROTECTED]> wrote
>
> > Now I am interested in learning how to DESIGN an object-oriented
> > version
The question was very interesting, and so where the answers.
> Don't at this stage worry too much about inheritanc
"bhaaluu" <[EMAIL PROTECTED]> wrote
> Now I am interested in learning how to DESIGN an object-oriented
> version
A useful distinction. You need to understand what classes are
before you can use them but the art of desiogn is indeed different
to the skills of construction
> Can I use the procedu
bhaaluu wrote:
> POOP: Python Object Oriented Programming/Programmer/Program(s)
POOP = borderline offensive and definitely annoying. Maybe you don't
know that poop is a synonym for excrement? Is that what you are trying
to learn?
> Now I am interested in learning how to DESIGN an object-ori
On Feb 5, 2008 1:13 PM, Marc Tompkins <[EMAIL PROTECTED]> wrote:
>
> On Feb 5, 2008 5:46 AM, bhaaluu <[EMAIL PROTECTED]> wrote:
> > What I'm interested in is the thought processes and/or
> > guidelines that Tutors employ when they sit down to design a POOP.
>
>
> The Code Smells page is as good a s
On Feb 5, 2008 5:46 AM, bhaaluu <[EMAIL PROTECTED]> wrote:
> What I'm interested in is the thought processes and/or
> guidelines that Tutors employ when they sit down to design a POOP.
Whenever I have a few free minutes and a desire to contemplate the
infinite (Hah!), I surf over to the C2 wiki.
78 matches
Mail list logo
