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

[boB Stepp]

On Sun, Aug 13, 2017 at 5:49 PM, Alan Gauld via Tutor <tutor at python.org> wrote:
> 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.

The result of a game between two players results in the need to
calculate new ratings for both players.  Ratings are attributes of
players.

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

Got me there!  Still stuck in the old procedural paradigm.

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

You understand correctly!  The primary purpose of this project is
breakout of procedural programming and break into OOP.

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

I just finished reading a couple of online articles about CRC cards.
I have some old index cards lying around.  I will have at it.

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

The two most obvious classes that jumped to my mind from the get-go
are Player and Game.

Thanks, Alan!

-- 
boB