Learning OOP...

[Alex Martelli]

"Glyph Lefkowitz" <glyph at twistedmatrix.com> wrote in message
news:mailman.992131396.542.python-list at python.org...
    ...
> Furthermore, I'd say that creating reusable code is *wrong*.

Interesting strawman, but you haven't come anywhere close
to 'proving' it in the following.

> Is libjpeg software reuse?  Probably not classified as such, but

Of course it's reusable.  So, why was it wrong to create it?

> 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;

Sure!  "The unit of reuse is the unit of release", as per Robert
Martin's "release-reuse equivalency principle".  RM is an OO guru,
by the way.  This doesn't necessarily imply class-centered thinking
to the detriment of proper modularization...:-).

> 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.

"Interface segregation principle", "dependency inversion principle",
etc.  Again, www.objectmentor.com has good papers on this:-).


> 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

Except that it's not, when applied well.  Python shows well how
suitably designed inheritance can make for smooth framework-code
reuse, e.g. in sgmllib/htmllib and the whole server hierarchy.  Code
generators should generate base-classes that are specialized by
inheritance, *NOT* by editing generated sources (a round-trip
nightmare).  Mixins allow seamless reuse.  Etc, etc...

It's true that implementation inheritance CAN too easily create
unintended strong coupling.  Scott Meyer's rule of thumb to
"never inherit from a concrete class" (in a C++ setting) shows
to what extremes one could go to ward off that danger...

> things).  Also, some systems which claim to be "OO" also have static
> typing, which partially negates the value of sending messages.

...and partially enhances it.  Again, it demands very solid design
(I wouldn't be Pythoning if I didn't think the flexibility of dynamic
typing was more often useful than the rigidity of static typing,
but I do have to play devil's advocate on this thread, I think:-)
but when you have it you're well placed.  Templates (or other
mechanisms for compile-time genericity) recover a lot of that
flexibility at no runtime cost -- Coplien's "pattern without a name"
is IMHO mostly aboyt that (template <class X> class Y: public X,
etc).  Basically, templates give you signature-based polymorphism,
like Python's, at compile-time only (thus less flexible, but easier
to generate speedy code for, and sometimes allowing somewhat
earlier error diagnosis).


> > >  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,

I'd like to see you say that to Bertrand Meyer's face, given how
intensely he maintains that "the spirit of OO" is statically typed!-)
Me, I might quote the Bard by saying "a pox on both their houses",
but I'll take the reverse tack, praising BOTH dynamic and static
typing.  I think OO works well with both, in different ways.

> 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.

Making software resistant to change is neither an intrinsically
bad thing, nor one at odds with software reuse.  I DO want the
software that I'm reusing to be unchangeable from the point
of view of behavior that I, the reuser, observe.  If static type
checking helps increasing the "firmitas" of the software I reuse,
that won't impede its "utilitas" nor its "venustas" from my POV
("firmitas, utilitas, venustas" are Leandro Alberti's and Palladio's
three principles of architecture -- solidity, usefulness, beauty --
they were writing about buildings, but, as we know from the
impact of Alexander's ideas on modern software engineering,
building architecture and software architecture may have more
intellectual and cultural connections than one would suspect).

The 'open-closed principle' is relevant here...


> 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

Nolo contendere here, but it's SO important it's worth quoting
just to increase the likelihood that it gets read:-).

> 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.

XP can definitely be commended.  And if one is a static typing freak,
that doesn't necessarily mean giving up on XP -- it just takes a _bit_
more upfront design and makes refactoring a bit more work, but as
Fowler's book "refactoring" (all examples are in Java) and Martin's
take on XP (thinking mostly of use in C++) show, XP is not _just_
for dynamic languages such as Smalltalk and Python (though they
do help:-) -- it's a lightweight development process that can be
of use in a variety of design and development settings...


Alex