"Tiger12506" <[EMAIL PROTECTED]> wrote> >> [Background from Alan] >> ... Thus the context object should respond to some message >> from Pizza and in this case the Pizza should hold a reference >> to its context manager(probably a screen or grid of some sort). > > [disclaimer] > This email has particularly strong personal opinions about coding > practices. > I do not wish to personally offend anyone, and if you feel that you > have > been offended as such, or that you disagree, please do not bother > emailing > this list to tell me, excepting that you provide an excellent case > promoting > your views that someone may be able to apply to make their code more > intuitive/sensible. This email was provided for just such a reason. > [/disclaimer]
Noted :-) >> The context manager is responsible for tracking the objects >> being managed, but the objects remain responsible for >> managing their own state. > > [rant] > This phrase right here is a dead giveaway to me that Pizza should > have > little control over how it moves. A Pizza must be completely aware > of its > current position (being part of its state) and at the very *most* a > set of > rules governing general falling behaviour. I like the idea of a > context > manager that is perhaps a container for Pizzas that oversees their > behavior, > but I dislike the idea that a Pizza knows specifics about its rules > for > positioning such as collisions or etc. that it has to communicate to > the > context manager and/or other Pizzas. I'm confused about what you dislike about this. You agree that the Pizza shouldn't know about other Pizzas and is thus unable to do its own collision monitoring. But if the Pizza is, as I surmised, a Pizza that falls under its own control as implied by the description "a Falling Pizza", then without it notifying the context manager (screen, board, collection or whatever) how will the thing that does know about the context be able to determine whether a collision has occured - assuming that it needs to. > Maybe I am becoming too used to lower > level languages, not fully siding with abstraction. That's possible :-). OOP was introduced to add abstraction to lower level concepts and sometimes that abstraction hits performance and requires extra code at the micro level, but usually does so by simplifying design at the macro level. This is one reason that true OOP(as opposed to using objects) is rarely used on small programs and classes in those problems tend to be used more as data containers somewhat like an old fashioned C struct or Pascal record. > I just see that we have suddenly introduced to new levels > of redirection to achieve the same result, Not entirely, by using indirection we have decoupled the class from the solution thus increased reusability. If you will never need to reuse a FallingPizza then of course it may be just as effective to use direct intervention but in doing so you break one of the fundamental principles of OOP. (And my comments were explicitly concerned with good OOP style) > instead of the list changing the elements. Definite benefits for > messaging > models, but this /feels/ akin to filling out tax forms so that the > government can tell you how you filled them out incorrectly. The messaging overhead in Python (as in most OOP languages) is not onerous and if dealing with lots of different Pizza objects might even save code due to the potential to remove if/elif constructs by relying on polymorphism. It would be different if we were talking about setting the objects up in different processes and communicating via an ORB but in practice its only a couple of function calls. (Of course if we did later need to split the objects over proceesses the messaging solution is much easier to adapt to using an ORB...) > A similar somewhat questionably connected problem involves my > dealings with > the Render method of the IPicture interface. Sure, you can directly > apply > the picture to the device context or if you like we have a Render > method > that will automatically change the coordinates so that you have to > convert > them back to display it. Abstraction isn't everything. No, I agree, abstaction isn't everything and occasionally for performance reasons you need to break down an abstraction layer. But in my experience I've only had to do that a couple of times. And Abstraction does give huge benefits. For example in the Picture example if you follow the protocol approach its trivial to swap device contexts from screen to printer to terminal to braille panel etc etc. But rendering by hand will usuially involve completely rewriting the renderer for each new device. If you know you will only ever have one device then direct rendering is a valid option. One of the interesting things about engineering (any branch, not just software) is that "rules" are there for guidance and engineering skill and experience tells us when it will be safe to break them. The smaller and more specific the task at hand the more likely that rules can be broken. But broken rules increase risk that you will incur extra cost later if assumptions change. HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
