[Tutor] Why Won't My Pizza Fall?

[Alan Gauld]

"Tiger12506" <keridee at jayco.net> 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