{Q} OOP Animal class.

[richard_chamberlain]

I believe Zargroves get pretty upset if someone mentions Blarndoogle's
splointers. So we shouldn't say anything more.

Richard ( ;-)

Will Ware <wware at world.std.com> wrote in message
news:FwF6Iy.G0I at world.std.com...
> johnvert at my-deja.com wrote:
> > 1. I call the method reply()
> > 2. The interperter sees reply() does not exist in class Hacker
> > 3. It goes one class up the hierarchy to class Primate
> > 4. reply() doesn't exist in class Primate
> > 5. It goes one class up the hierarchy to class Mammal
> > 6. reply() doesn't exist in class Mammal either
> > 7. It goes one class up the hierarchy to class Animal
>
> Good so far. As you suspected, this is where things start to
> get a bit dicey. My understanding (which perhaps others will correct
> if necessary) is that each method search is a separate thing, and in
> each case we are prepared to climb the inheritance tree. So when
> reply() calls speak(), we begin the whole search process anew, starting
> at Hacker. Hacker doesn't have a speak() method, but Primate does,
> and that's why we use Primate.speak().
>
> > I really want to have a solid understanding
> > of this because it's important to understand OOP.
>
> OOP is primarily a flexible way to let you make say things like this:
>
> A Blarndoogle is an object with this set of behaviors.
> A Flugestroid is almost exactly like a Blarndoogle, except
> that it splointers the way a Zargrove does, and it has its
> own unique way of flithering, different from either a
> Blarndoogle or a Zargrove.
>
> The idea would be that the behaviors for Blarndoogles and Zargroves
> would probably already be thoroughly debugged when you were ready to
> define a Flugestroid, so the only really new thing you need to do is
> define how it flithers. That is, all your effort is focussed entirely
> on what's new about this situation, not on re-implementing and
> re-debugging existing behaviors. At least that's the theory.
>
> Some languages (Python generally not among them) stress a "privacy"
> aspect of objects, that there should be information available only to
> the object and not to anybody else, and the object can therefore define
> how others get to view or modify that information. Python mostly
> doesn't worry about object privacy much; you can create private
> attributes by starting attribute names with two underscores, but you
> don't have the elaborate machinations of public/protected/private you
> get with C++ and Java.
> --
>  - - - - - - - - - - - - - - - - - - - - - - - -
> Resistance is futile. Capacitance is efficacious.
> Will Ware email:    wware @ world.std.com