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

[Alan Gauld]

On 13/08/17 21:15, boB Stepp wrote:

I return to the point I made about focusing on the
objects not the functionality.

> It is not very well-written in my opinion.  But anyway ... The basic formula is:
> 
> new_rating = old_rating + K_MULTIPLIER * (opponent_rating -
> old_rating) + K_ADDER * (your_result - opponent_result)

What is being rated? A player? A game? a set of games?
The rating calculation should probably be a method of
the object being rated rather than a standalone function.

If you make it a function you will probably have to pass
in lots of data objects (or worse use a lot of globals).
In OOP you want the data to be in the object and the
method to use that data to achieve its aim.

> I generally start as above by dividing things up into broad areas of
> functionality 

Which is exactly how you write procedural code - the technique
is called functional decomposition.

But if your objective is to use OOP you should start by identifying
the objects. Then you can assign the functionality(responsibilities)
to which ever object (or set of objects) is appropriate.


> to be a rather straightforward translation of a formula with various
> conditions into code, returning the newly calculated ratings 

Note that I'm not saying your approach is wrong in a general case,
it may well be the most appropriate approach for this application.
But it will not easily lead to an OOP style solution, and that I
thought was the secondary(or even primary?) objective of this
exercise?

> So how detailed should I plan out each broad section of the program
> before writing any code?  Alan seems to be suggesting getting a firm
> handle on initially imagined objects and their methods before any code
> writing.

You need some kind of idea of the classes you are going to write.
The CRC description only needs to be a few lines scribbled on a
sheet of paper or in a text editor. In OOP you are building classes that
represent instances. Your solution is an interaction between the
instances (objects). Without a fairly clear idea of how the objects
interact you can't make a sensible start. You don't need to analyse
the whole system (and indeed should not do so) but start with a
couple of basic use cases - what initiates the action? What are
the  preconditions(eg. data etc), the outcomes, the possible error
conditions. When you understand a use case enough to code it, do so.
Or even just the initial class/object.

It's a good idea to get an early code structure in place, maybe
a Player class? It seems that this is the thing being rated.
Maybe a game class since it seems that game (results and players)
are used in the rating algorithm. So your Player probably needs
a list of past games?

-- 
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