"Battleship" style game
steve at holdenweb.com
Wed Feb 25 22:07:36 CET 2009
Shawn Milochik wrote:
> On Wed, Feb 25, 2009 at 3:15 PM, Diez B. Roggisch <deets at nospam.web.de> wrote:
>> Not really. The point about properties is that you *can* make attribute
>> access trigger getter or setter code.
>> But not that you do unless there is an actual reason for that. The way you
>> do it now is simply introducing clutter, without benefit. Your class would
>> be half the current size - without loss of functionality.
> It is true that it would be fewer lines of code with the same
> functionality, but it's better practice to have that framework in
> place so that any changes made in the future wouldn't break any of the
> code accessing my class. Obviously this is a fairly simple game that
> has a fixed set of rules, but I'm trying to cultivate good habits, and
> I don't think that doing it this way is anti-Pythonic.
> Unless, of course, anything I said is wrong, which is always possible.
> If I'm missing a bigger-picture idea, I'd like to know about it.
The point of using property() is that you can start out using attribute
access on its own (which is the standard Python way to do things:
getters and setters are seen by most as redundant code).
Once you need programmed access on read and/or write, leave the client
code (the code that accesses the attributes) as it is, but turn the
attributes into properties so that the functions are invoked
automatically on attribute-style access.
So I believe what Diez was saying is that by using properties in your
existing code you are getting the worst of both worlds - unnecessarily
complex objects, and code that uses those objects by calling methods
when it could be accessing attributes (or properties - depending on the
implementation). At least this is true of your Ship test code.
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
More information about the Python-list