On Sun, Aug 13, 2017 at 5:49 PM, Alan Gauld via Tutor <tutor@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor