[program-l] Re: Python: Please Help Me Think Out Loud About When To Make Classes And When Not To Make Them

From: "R Dinger" <rrdinger@xxxxxxxxxx>
To: "programming" <program-l@xxxxxxxxxxxxx>
Date: Wed, 31 Oct 2012 12:15:18 -0700
Hi Jim H.

I have a few random thoughts to add to this discussion.

Regarding basic OO design: Object oriented programming has its roots in 
Simula-67, which was a simulation language.  So I like to approach a design as 
the simulation of some task/system/process that you wish to automate.  So how 
to model a chess game?

First, what sort of objects are involved that need to be simulated?  Certainly 
you need a Board, the various pieces (a piece base class and a class for each 
specific piece type like King, Queen, Rook etc derived from the Piece base 
class seems likely.  Since chess has its own language you will need a Parser to 
determine the moves.  Note parsing is a process and can be a procedure if you 
want, but I prefer a Parser class and a Lexer class as well.  So a move class 
may be needed and you may also want a Game object that keeps the current game 
record or list of Moves.  And last, you will often need a Controller that 
manages the whole thing, which may be a procedure rather than a class.

Note all the things that are object classes all retain some sort of state.  The 
Board for example will retain the current position of the game.

I suspect the Board class would be the main or central class in the system.  I 
like to think of an OO system as a loose collection of classes that exchange 
information among themselves to accomplish something, in this case analyze 
chess moves or whatever you have in mind.  That brings up a good point -- what 
do you want this system to accomplish?

Regarding the coupling of cmd with the system: You are absolutely on the 
correct track keeping the cmd class out of the actual working modules.  Back in 
the 1980's the SmallTalk folks came up with the so called Model-View-Controller 
(MVC) approach to user interfacing.   The idea is that the model is your actual 
application or system.  You may have several Views of that Model, say a text 
View or a GUI View and the two are separate.  Finally, the Controller mediates 
and passes messages among all the working parts.  Today's systems often combine 
View and Controller into a single entity.

So keep your application independent of the user interface and you will be able 
to switch them out.  In the case of cmd, it should call functions (pass 
messages) to the Board object, which in turn does something to change its state 
and may return a success or failure message.  During the execution of the 
Board's function, it may call other object's functions.

Think of an object as something like a real world object such as a TV set.  It 
can be set to a channel (change its state) where it plays a function showing 
the current show.  You can change the volume state or brightness.  The TV is 
just an object with some buttons you push to change the state.  You do not need 
to know much about the internals to make it work, you only need to know which 
buttons to push!

If any of this makes sense, your nest step is to make lists of what each object 
should potentially do or its functions.  This can be arranged and rearranged 
for a while until you are happy with the design.

As for that Board class, yes I would make it a dictionary.  That is a great 
simulation of how it would work.  Don't worry about the choice of inheritance 
or inclusion as in the end it will not matter.  You can change your mind and 
easily change the code.  I lean toward inheriting like:
class Board(dict):

But a dictionary attribute could be accessed by overloading the [] function and 
it would appear the same in the code.  Be sure to supply bounds checking on 
that dictionary so you can't move to square a9 though.

Richard
----- Original Message ----- 
From: Homme, James 
To: program-l@xxxxxxxxxxxxx 
Sent: Tuesday, October 30, 2012 11:25 AM
Subject: [program-l] Python: Please Help Me Think Out Loud About When To Make 
Classes And When Not To Make Them


Hi,

I think that my chess project is one in which it's OK to make the class that 
uses the cmd class, but is also OK to import a file that has chess related 
functions, but is not a class. If I'm wrong, please tell me. Here's how I view 
the project in my mind right now, and where it's going. But the big question in 
my mind is this. What makes you either decide to make classes or not make them?



I now have a file that I'm going to change so that it returns the results of 
the functions it calls from my chess board module. In order to make the 
functions in my command file see the ones I'm making in the chess board file, I 
put an import statement at the top. When I did this, my functions could call 
the ones in my chess board file. 



I'm going to have functions like new game. I think that this makes it so that I 
don't need to instantiate a chess board class. I say this because of the way 
this whole thing is constructed. Every time

I type a command, it gets ready to receive a new one.  I'm keeping the help 
functions in my commands file, though. I'm not going to migrate them over, or 
put functions in the chess board file that return help text. I may have to 
change my mind, but this is how I see it working right now.



The only thing my commands file will do is start and run the command loop. 



I'm hoping that once I learn how to make GUI programs, I can simply swap out my 
command line processing file and make the GUI file just use the functions in 
the chess board file. So, in stead of a command loop, it would make some sort 
of event loop or whatever that GUI thing is called that waits for you to click 
stuff and choose stuff. 



So theoretically, I can put out a command line version of my program, and a GUI 
version of it. 



But what concerns me is the question of whether I'm constructing it this way 
because I come from a procedural programming back ground and subconsciously 
want to avoid making classes, or whether this is the best way to construct the 
project. 



It seems like a nice way to divide things up, though, so that it helps me think 
of each file having a set of functions. For example, maybe there would be a 
third file that does nothing but save and load game data from disk, assuming 
that I want to build in the capability to save and load games in progress, and 
I see no reason I wouldn't want to do that. Here again, though, I'm thinking 
that the chess board file would import the one that loads and saves the data. 
And I'm thinking that the file that does that may not need to contain a class 
that does this. I'm not that far in my thinking though.



Thanks for listening.



Jim



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

This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed. If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it. If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.
References:
- [program-l] Python: Please Help Me Think Out Loud About When To Make Classes And When Not To Make Them
  - From: Homme, James
[program-l] Re: Python: Please Help Me Think Out Loud About When To Make Classes And When Not To Make Them

Other related posts:
