On 04/07/18 12:08, Daryl Heppner wrote: > If you have any suggestions for continued self-learning (books, > courses, etc.) I'd appreciate any tips.
So far as OOP goes you can't go far wrong with the latest version of Grady Booch's OOAD book. I've read both the previous versions and the latest update is the best yet. > A bit of context, in case you're curious - we're parsing the XML for > load into a T SQL database for reporting purposes which is why I've > parsed each value to a unique "cell". The print statement is merely a > QA step before ultimately making use of the pyodbc method. I guessed as much. As for the database inserts I'd consider making them part of the class init method, so once you create the new class instance it automatically saves itself (or updates if the ID already exists?) > The need to extrapolate the full rent schedule is to address a few > reporting needs. Free Rent, where applicable, is not expressed as a > dollar value with a specific date. Rather, it is described as a > percentage of Base Rent with a reference to the month in which it > applies. A lease can have multiple Free Rent periods which may or may > not be consecutive and there are several examples where a Free Rent is > applied in the 2nd month and again in the 14th month which means that > the dollar value of the Free Rent could be different if a rent step > occurs at the end of the first year. Put the calculations as methods into the corresponding classes. If necessary break them up so each class does only its own bit of the calculation. Remember the adage that "objects do things to themselves". If an object owns a piece of data it should be the thing that operates (including doing calculations) on that data. Calculations are operations on objects not objects in their own right. (Unless you are building a calculation framework, like Matlab say...) One of the most common OOP anti-patterns is having some kind of calculator object that fetches data from all the surrounding objects, does a complex calculation then stores the result into some other object. Instead the calculation should commence in the target object and it should ask each of the supplier objects to do their own bits only returning to the target the end result of their subcalculation. The target object should, in turn, only be performing calculations on the results returned plus the data actually stored in the target itself. Of course it is not always that clean but if the object data is partitioned well it should be pretty close. But it takes most non-OOP programmers a little time to turn their thinking inside out like that. So don't sweat if it feels unnatural to start with. -- 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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
