On 11 September 2017 at 16:32, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > This leads to a subtle question... If the focus strictly on OOP, or do > you intend to supply some precursor OOAD stuff. OOP is just implementation > and usage, but without some understanding of OOAD the concepts may come > across as just magic. > > IE: classes are templates from which one instantiates objects; > instances of a class share methods, but each instance has its own state. > > Just doesn't help in figuring out what qualifies for a class vs instance, > what should be a method, and what is state.
That's a very good point - and not one I'd really thought about (this isn't a formal training course, more of a set of mentoring and knowledge sharing sessions where I'm helping this guy get into "actual" programming rather than just hacking the odd VBA macro etc). I'll make sure I cover some of the design aspects in my discussion. >>OK. Replace that with "I think my student would find it motivating to >>see a GUI style of behaviour, even if he had to take the >>implementation of that part of the program on faith". He's used to the >>idea of writing plugin code that fits into a framework, so this would >>be a familiar idea to him. >> > Unless the "game" is going to be playing Chess (in which case you are > looking at way more than an intro to OOP), the GUI comes down to a grid of > squares, sprites/icons for the pieces, and a way to select/move the > piece... Yep, that's about it. But the point is, that's the framework, not what I actually want to get him implementing. > And the only logic left to implement would be validation of the > moves, and tests for capture when one moves into an occupied square. Not > really that much left for the student. I'm not looking at actually implementing chess. The idea was prompted by a programming exercise my son was given, that was about programming a series of classes modelling robots that know their position on a grid, and when told to move, can do so according to certain rules. One moves in a straight line till it hits the edge, one moves in a random direction, some bounce when they hit an obstacle and some just stop, etc. The idea is to demonstrate classes and inheritance to model common behaviours and objects holding state that the behaviour acts on. The original exercise (which used Java) just had the program print out the objects' co-ordinates at each step. I thought that visualising the results by actually showing the objects moving would be better. (And a quick discussion/demo with the guy I'm training showed me I'm right - his reaction was "wow, that looks really impressive" :-)) > Again, it sounds more like you need a language agnostic discussion of > OOAD -- not language specific OOP. Mostly agreed. But we have a tendency to spiral off into pure theory far too easily - and then my student doesn't remember what we covered because it wasn't grounded in anything practical. So I want to have a practical (and better still, visual) example to keep us focused. Thanks for the comments, Paul -- https://mail.python.org/mailman/listinfo/python-list
