[Tutor] [Slightly OT] Inheritance, Polymorphism and Encapsulation

Michael Langford mlangford.cs03 at gtalumni.org
Wed Sep 19 03:26:45 CEST 2007


> "Place the following three in order: Inheritance, Polymorphism,
Encapsulation."

Inheritance: Syntactic sugar that's not really needed to make a well
organized system. Often overused, especially by programmers in big
companies, beginning students of programmers, green engineers, and
professors. In practice hides a lot of data, often making behavior
surprising, therefore harder to maintain. Can be used in limited situations
to great advantage, but like cologne on car salesmen, is used in greater
amounts than it should be. One should always ask, can I make a simpler
system with composition.

Polymorphism: The process of creating many classes which a single interface
which are then all used by an object that doesn't know or need to know the
type. Many people think you only get this by using inheritance and therefore
use inheritance many places a simpler, less opaque, more lightweight
solution will work. Most dynamically typed languages (most notably, python,
ruby and smalltalk) don't even require you specify the interface explicitly
to get polymorphic behavior.  C++ templates can do non-explicit interface
polymorphism, however in a more complicated, blindingly fast to run,
blindingly slow to compile way.

Encapsulation: The process of taking what shouldn't matter to the external
world, and locking it behind an interface. This principle works best when
put into small, specialized libraries and designed for general use, as this
is the only encapsulated form that is shown to last over time. Supposedly
something OO based design allows, but in reality, the coupling among classes
varies in differing amounts. The module/public visibility of Java is a good
compromise with classes that hides some data but share some with certain
other classes. C++ has large issues for historical reasons on this front, as
the implementation section of a class is largely revealed through the class
definition.

     --Michael
-- 
Michael Langford
Phone: 404-386-0495
Consulting: http://www.TierOneDesign.com/
Entertaining: http://www.ThisIsYourCruiseDirectorSpeaking.com

On 9/18/07, Ricardo Aráoz <ricaraoz at gmail.com> wrote:
>
> Stephen Nelson-Smith wrote:
> > Hello friends,
> >
> > Over lunch today some colleagues discussed a question they are using
> > as a conversation starter in some preliminary chats in our developer
> > hiring process.
> >
> > The question was:
> >
> > "Place the following three in order: Inheritance, Polymorphism,
> Encapsulation."
> >
> > They specifically did not define in *what* order, leaving that for
> > the answerer to decide.
> >
> > I responded thus:
> >
> > Encapsulation comes with OO - you get it for free.
>
> Encapsulation does not come with OO. It is something you must code in
> your classes.
>
> > Polymorphism is a
> > hugely important enabler, but this in itself is enabled by
> > Inheritance, so I put them in this order: Inheritance, Polymorphism,
> > Encapsulation.
> >
> > My colleagues felt that of the three options this was the least
> > satisfactory, and showed a lack of understanding of OO design.  One
> > even suggested that one could have polymorphism without inheritance.
> >
>
> IMHO you can have polymorphism without inheritance. Why shouldn't you?
> It does NOT depend on inheritance I guess you could say it depends on
> namespaces defined by the classes, but not inheritance.
> _______________________________________________
> Tutor maillist  -   Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20070918/46d00d30/attachment-0001.htm 


More information about the Tutor mailing list