[Tutor] Long post: Request comments on starting code and test code on chess rating project.

[Alan Gauld]

On 13/08/17 06:22, boB Stepp wrote:

> The intent of this project is more than just calculate chess ratings.
> I also envision being able to store a record of all game results and
> player information for my school chess players that I give lessons to.

That's fair enough but OOP or no OOP the basic advice is the same:
divide and conquer. Make the admin and logic parts of the application
separate and work on the core of each. Bring them together via the
UI (which initially may be a set of CLI tools...).

> I have started my coding with a RatingCalculator class.  The intent of
> this class is to gather all methods together needed to validate and
> calculate chess ratings.  

That may be appropriate in that it is often the case that you have a
single class representing the applications a whole. But a calculator
sounds like a low level helper class to me, possibly encapsulating the
detailed algorithms used top create the ratings. I'd expect there to be
potentially several subclasses representing different algorithms. I'd
expect the calculator instances to be passed as an object into the
rate() method of a game object...

> My intent is to only ever have a single
> instance of this class existing during a given running of the program.

I notice Steven's post, to which I'll add amen.
Singletons in Python are rarely needed, just make your game
a module. Maybe rethink the role of the calculator class.

> added any methods yet.  Currently I am adding class constants that
> will be used in this class' methods. 

Since internal data/attributes should support the operations
its usual to start with the operations before defining
the supporting data. Seriously consider using the CRC
methodology to identify and describe your projects classes.
It can be in a single document rather than physical cards,
the important thing is to briefly describe what each class
is called, its responsibilities(often becoming methods)
and collaborators (other classes which become attributes
or method parameters).

>  These constants are for internal
> class use only and should not be altered from outside the class.  

It sounds like they are to be shared values across
methods of various objects/methods, that suggests
putting them in a shared class or module.

> is the current state of the main.py program (Which will probably be
> broken into multiple modules as the project develops.):

While Python doesn't require using a module per class, it is better to
keep related classes in a single module so I strongly suggest breaking
it into multiple modules. At the least 3: rating engine, admin and UI.

> """Module to process chess ratings."""
> 
> class RatingCalculator:
>     """This class contains methods to validate and calculate chess ratings."""

I'd suggest that validation and calculation are two very different
things. Probably requiring separate classes. But we need more detail
on the objects involved. What does a rating rate - a Game? a Move? a
strategy? And what does validation validate? A rating perhaps?
You are in danger of focusing on the verbs (rating calculate,
create, edit, etc rather than the objects that do these things.
You need to turn your initial thoughts away from what the application
does (traditional procedural coding style) and onto thinking
about what kind of objects make up the application. It's common
to start with a fairly long list then, as you apply CRC analysis(*),
realize that many of the objects are only attributes. But it's better
to start with too many objects than to try to squeeze functionality
into just a few uber-objects.


(*)If you discover that a candidate class has no responsibility
except holding one or maybe two pieces of information, or that
it only collaborates with one other object you may decide it
only needs be an attribute not a full class. Also, especially
in Python, many collections of classes will turn out to be
standard container types such as lists, dicts, tuples etc.
Or standard classes such as dates/times. Making these early
win decisions is one of the biggest reasons for doing CRC
analysis IMHO.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos