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

Michael Langford mlangford.cs03 at gtalumni.org
Wed Sep 19 09:51:35 CEST 2007


I do think this is a good question for getting a sense of where a
person's understanding is.  I wonder how much this understanding is a
pre-requistite for being a good developer... not too much I hope!

A good developer is a very loaded term. :o)

There are a lot of good programmers who are bad developers. A lot of being a
good developer is getting things done that work well enough to supply
whomever is downstream from you at work. This goes way beyond programming,
and is much more about being an effective human being than being good at
programming. It also has to do with several things such as source control
tools, ticket tracking tools, testing, debugging, and deployment as well.

You will find yourself making more informed choices on things and debugging
things a lot better the more of this technical programming stuff you pick
up. A good compiler/interpreter book and a lot of experimentation will
really open your eyes on a lot of this, as will just doing your job while
constantly reading reading reading about what you are learning and doing
things like talk with your co-workers at lunch about hiring tests, and
participating in online discussion boards.

In addition you should try doing really hard things that break or come
really close to breaking the tools you use. But not too hard, you have to be
able to *do* them after all. Learning how VM's and interpreters and
compilers work, then understanding the concepts behind why they work that
way really helps give you a framework to hang an understanding of what's
going on in a program. One way to get this knowledge is to start far in the
past and work forward. Another is to dive deep into something from today.

I will say if you're already in the workforce and not headed back out to
school, the onus will be on you to pick up more of this. Much of the
conceptual stuff you won't hear at work, except occasionally overheard in a
discussion assuming you already know it. You'll have to ask questions, and
you'll have to read up on it afterwards, because often your co-workers won't
have the whole picture either.

      --Michael

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

On 9/19/07, Stephen Nelson-Smith <sanelson at gmail.com> wrote:
>
> Michael Langford wrote:
>
> > 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.
>
> Pretty much exactly what my colleague said.  Having thought about it I
> understand this.
>
> > 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.
>
> Also what my colleague said!  This is the bit I had missed.  Perhaps I
> need to rethink / reload my understanding of polymorphism.
>
> > 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.
>
> Interesting.  And again revealing of a weakness in my understanding.
>
> I do think this is a good question for getting a sense of where a
> person's understanding is.  I wonder how much this understanding is a
> pre-requistite for being a good developer... not too much I hope!
>
> >      --Michael
>
> S.
> _______________________________________________
> 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/20070919/7a5be8a4/attachment.htm 


More information about the Tutor mailing list