Poly Couples (was: How to motivate use of OO?)

Stefan Ram wrote:
nassegris@xxxxxxxxx writes:
So now I'm asking you people, what should I tell him?

the Refactor "Replace Conditional with Polymorphism".
(...) is the heart of why ObjectOrientedProgramming is
better.

http://c2.com/cgi/wiki?ReplaceConditionalWithPolymorphism

I assume your friend is using Microsoft® Windows, where files
are represented by areas within the Microsoft® Windows
Explorer. To print a PDF-File, he chooses the message »print«
from the context menu of the file area. To print a bitmap-File,
he chooses the message »print« from the context menu of the
bitmap-file.

He does not have to find out which program (method) is needed
to print a PDF-file or a bitmap file, respectively. He just
sends the same message »print« to any printable file object,
regardless of its type. A conditional was replaced with
polymorphism. I assume, he prefers it this way. Then, he knows
why it is better.

Fine. Oop is great for device drivers (like print drivers above),
animals, and shapes. But can we pleaaaaaase get something that reflects
what real people see in the real workplace? The vast majority of
software I write does not fit a device driver pattern. For example,
some use "employee types" with polymorphic methods for each sub-type as
a polymorphic biz example. In reality, you cannot divide employees into
a *clean* hierarchical taxonomy. And even if you did, new legal changes
could render the hierarchy useless, splitting existing categories, etc.
Lawmakers do not respect tree-ness. They don't care if new legislation
busts your nice little tree.

Thus, I've found it best to use a database to describe employees using
various attributes and flags. The code then processes these attributes
and flags without worrying too much about which taxonomy they are
attached to. The code is NOT shaped like a noun taxonomy. This is key
to FLEXIBILITY.

This way if the classification system for employees changes, as long as
the flags or attribs are the same, the code still carries out the
instruction. If the "noun" that triggers a given condition moves, such
as being tied to the department that you work in instead of an
individual person, then you only have to change the IF statement
expression a bit. Polymorphism would require *moving* the code because
the "responsibility" changes. Moving is a bigger change than altering
in-place. (Sure, you could get a fancy dancy OOP code processor to do
it for you, but one could make a CASE/IF statement processor also. I
too can build crutches.)

And the granularity of poly is often not fine enough. How do you
override HALF of a method? (without duplicating some behavior). IF
statements are simply more bendable and flexible to handle real-world
changes. You can refine them without moving lots of code around.
Polymorphism artificially couples your code to specific nouns and
specific noun taxonomies. If one is going to hammer on "coupling", then
you cannot pick and choose which coupling you keap and which you reject
without justification. If *all* coupling is bad, then poly is coupling
to nouns and noun taxonomies and is therefore bad.

-T-

.

Relevant Pages

  • Re: Poly Couples
    ... Please learn what polymorphism mean in CS. ... If *all* coupling is bad, ... to nouns and noun taxonomies and is therefore bad. ... def doThis: ...
    (comp.object)
  • Re: Poly Couples
    ... Please learn what polymorphism mean in CS. ... If *all* coupling is bad, ... to nouns and noun taxonomies and is therefore bad. ... def doThis: ...
    (comp.object)
  • Re: thoughts on OO design for processing messages
    ... BUT, as you can see, this is in structure very similar to the switch ... > to add itself to the reply queue. ... So, as you found out for yourself, the if *can* be replaced by polymorphism. ... > add a degree of coupling that I'm uncomfortable with. ...
    (comp.object)
  • Re: Disadvantages of "instanceof"
    ... generally not using one of the main features of ... Furthermore, by not using polymorphism in that way, you introduce close ... coupling from clients to your classes: Now clients have to know a lot of ... unnecessarily close coupling. ...
    (comp.lang.java.help)
  • Inquiry: Differences between coupling vs cohesion and encapsulation vs. polymorphism
    ... (aka high cohesion and low coupling) ... perhaps with the use of encapsulation and polymorphism. ...
    (comp.lang.java.programmer)