Learning OOP...

[Glyph Lefkowitz]

On 9 Jun 2001, Martijn Faassen wrote:

> Rod Weston <rod_weston at yahoo.com> wrote:
> > The reasons I feel a need to learn OOP languages are as follows:
> 
> >  3. I want to reuse code as much as possible.
> 
> While OO techniques can help here, don't expect anywhere close to a silver
> bullet. Creating reusable code is *hard*.

Furthermore, I'd say that creating reusable code is *wrong*.

To clarify: if code is "usable", that implies that it is a standalone
piece of software which does something that you want to use.  Is libjpeg
software reuse?  Probably not classified as such, but simple C programs
like that get a lot more "re-use" than their entangled, more OO
counterparts, precisely because of their simplicity.

One of the things I like the most about python is the first-class
treatment of modules.  A module is a far more important unit for useage
than an object.  (I do wish that Python had better support for packages;
syntax support for swalow in Py3k, anyone? :)).  If you plan to produce
assets which can be used again on a software project, *separate them out
into a separate project*.  Then dependencies are clearly maintained, and
responsability for the code remains where it should be.  Most OO "reuse"
involves copying huge blobs of code between projects, eventually evolving
massive, poorly understood, and subtly incompatible subsystems on multiple
projects.  Keep your systems small and have them communicate clearly and
sparsely over encapsulation boundaries, and your code will be useful for
years; and you'll never have to re-cycle it.

Insofar as OO helps, it is because OO has a simple and relatively
universal metaphor for communicating between programs written with vastly
different design assumptions, even in different languages: message sending
between objects.  However, OO also has the notion of inheritance, which is
a *huge* impediment to reuse between projects (but can be useful for other
things).  Also, some systems which claim to be "OO" also have static
typing, which partially negates the value of sending messages.

> >  5. I want strong and flexible data typing - I know it sounds like an
> > oxymoron.  I want the typing to be especially powerful (restrictive)
> > but I want to be able to define the constraints of the types myself.
> 
> This isn't the case for Python. Python is flexible and powerful but doesn't
> do constraints very well. :) We like it that way. A language like Java or
> Ada or (perhaps especially) Eiffel is better suited for that.

This is also, IMHO, against the spirit of object orientation.  Smalltalk,
frequently regarded as the "one true" OO language, has pure dynamic
typing, and relies upon that for many of the advantages ascribed to OO.  
Provable correctness requires type validation and compile-time checkable
assertions (preconditions and postconditions) but I don't believe those
have anything to do with object orientation.  Certainly, provable
correctness and static typing are at odds with reuse, since they make your
software more resistant to change.

> > 11. I want good quality but free or inexpensive tools - especially a
> > validated compiler to properly optimize my code for the task at hand
> > and catch as many errors as possible at compile time.
> 
> Python doesn't do any of this, except that it's completely free and excellent
> quality. I've worked with C++ which does attempt to do the catching of errors
> at compile time and optimization, and you see which newsgroup I'm posting
> in. :) Ada or Java or C++ would help for those things.
> (or say, Ocaml)

Do you know the rules for software optimization?

  1: Don't do it.
  2: (For experts only!!) Don't do it *yet*.

The easiest way to have a responsive, efficient program is to prototype
and prototype and prototype in a flexible, "slow" language, until you've
got the fastest possible high-level algorythm, then optimize for constant
factors by pushing the slow code into a "fast" language.  Transliterating
well-understood python into C is a relatively easy task and can give you
immense benefits; changing the structure of a huge C program to be more
efficient is complex and difficult to get right.

> > Not all the objectives relate to OOP, but most do.

> Just remember: OO is far from a silver bullet! Especially the whole 'reuse'
> advantage has been overdone in the beginning years.

Also try to form for yourself a clear definition of what "OOP" is.  Many
of these things are conventions which some OOP languages tend to follow,
but may or may not be a core part of what "OOP" is.  You seem to have a
pretty clear idea of your objectives; but I'd recommend taking a look at
the eXtreme programming books for a differing perspective on software
engineering.


                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://twistedmatrix.com/users/glyph