From: topmind on
Phlip wrote:
> coeval wrote:
> > When one says the main concept in OO is polymorphism, let me I have
> > some doubts.
> Have you read the book /Design Patterns/? The authors held themselves to the
> laudable goal of citing 3 real-life projects per pattern.
> Each had more, of course.

Those tend to be the domain of "systems software", an area already
over-explored with OO. Many of us want to see more business-oriented
examples rather than writing text editors and device drivers.

> > I read lot of books about OO to improve my skills but most of the time
> > the real world is completely different.
> The "real world" is the problem.
> Plenty of OO tutorials accidentally start with "OO works best because you
> can model the real world", or similar. This is heinous verbiage for one
> simple reason: If we discuss which of two OO models is better, saying "mine
> is better because it models the real world" adds nothing to the
> conversation.
> The OO model with the simplest implementation and least redundancy is
> better. The Real World _never_ obeys that guideline. But sometimes the best
> way to replace redundancies with flexibilities is with virtual methods.
> You use OO every time you open a file handle and write to it. The target
> could be a disk file, a console, a printer, etc. That's polymorphic behavior
> encapsulated behind an interface: OO.

Again, this is the device-driver/systems-software domain. There is a
derth of "good" examples from the business domain. I say "good" because
the few there are tend to have unrealistic, oversimplistic assumptions
behind them. The authors appear ignorant of "real world" custom
business software developement and the change patterns surrounding it.



From: Christer Ericson on
In article <1119286127.079006.327060(a)>,
apalala(a) says...
> [...] As big as Dijsktra's proving structured programing was complete.

Are you refering to that sequencing + selection + repetition is
complete with regards to expressing all algorithms? If so, that
result is due to Böhm and Jacopini (1966), not Dikjstra.

> As big as Hoare's concept of "monitor", which provided a new insight
> into parallel programming

That should read "Brinch Hansen's concept of 'monitor'."

See Chapter 6 of Brinch Hansen's memoirs for the details of
Hoare appropriating the concept from Brinch Hansen (page 112-
113 specifically):

Christer Ericson
From: coeval on
I was involved to develop a control quality application for a major
company in early 90's. We used C and a C++ pre-processor from the Irish
company Glockenspiel, and GUI library CommonView.
It was my first object-oriented application and I was at the "top of
my art".

But... the development was painful, senior management wanted to have a
complete objects-oriented application, so we ended by re-inventing the
Btrieve , an ISAM library, was wrapped simulating a database.
100,000 lines were produced, no design, no documentation. After 6 years
manpower, two project leaders sacked, the application went live and in

Few times after we won a fixed price contract for large music company,
surprisingly the application was developed with Clipper/DBASE,
management directors were reluctant to use the new object state-of-art
Just 3 people and 2 months after the application was in UAT, I was
flaggerbasted how fast the application was developed. Clipper/Dbase
built-in functions were far more better than in-house C++

On 2 days developers designed all reports, when I had to do the same on
my "object-app" I was doomed. I ended up writing a Query Object
Framework (qof) simulating SQL queries.... Arrgg!!!

That is the real world, even today, after almost 15 year nothing has
really changed.

Don't trust methodologist, refactorist, Gof, pattern, anti-patterns,
distilled stuffs....

just go back to the basic: maths, logical sets.

Use a top-down procedure to refine your design without thinking about
the programmatic language you are going to use.


From: Robert C. Martin on
On 20 Jun 2005 09:41:01 -0700, "topmind" <topmind(a)>

>> >I have a question of you. If for the sake of argument
>> >the changes *are*
>> >random, do you still think polymorphism would simplify changes?
>> Yes, because polymorphism help me to decouple. Decoupled modules are
>> easier to change.
>First of all, I thought you agreed that not all coupling is bad
>(remember the suitcase analogy?). Thus less coupling is not inherantly
>good or bad. Your line of reasoning appears inconsistent on this.
>It seems coupling is "good" if it helps simplify changes, and "bad" if
>it does not. But this gets back to probabilities of possible change

Of course. The reason I stress DE-coupling is that it is
intrinsically harder then EN-coupling. I can couple two modules
simply by having one mention the name of the other. But Decoupling
two modules that are already coupled takes a bit more skill, and tools
like polymorphism help a lot.

Not all coupling is bad. But deciding which couplings are good or bad
is not always evident at first. Also, as the software matures
couplings that used to be valuable may become more and more harmful.
So I need good tools to help me break and re-route existing couplings.

>Copy-and-paste actually *reduces* coupling because it lets things be
>independent, for example.

I disagree, rather strenuously. Copy-paste does not reduce coupling,
it hides it. An algorithm that is pasted into a dozen different
modules creates a bizarre coupling between those modules. Even though
the modules don't know about each other, they have a reason to all
*change* together. Each instance of the algorithm is NOT independent
of all the others. A change in one almost certainly implies that the
change must be made in all the others.

Using the Template Method or Strategy pattern to resolve this kind of
duplication is almost always better than allowing the individual
pastings to co-exist.

>So, let's focus on change impact. Can you answer in terms of change
>impact instead of "coupling"? That would be helpful. If you would
>rather stick to "coupling", then first we need to clarify what kind of
>coupling is good and what kind is bad.

No, we don't have to do that. Any freshman software developer knows
that it is easier to change module X if no modules depend upon it; and
that it is harder to change module Y if many other modules depend upon
it. Managing couplings is a matter of moving volatile code into
modules that nobody depends upon; and moving non-volatile code into
modules that many modules depend upon.

>How about we explore a code change scenario. I have five case statement
>items (occuring once) and you use polymorphism instead. Now suppose the
>change is that the items become non-mutually exclusive (yep, that word
>again). Do you claim the total change effort for poly will be less than
>what it would be for the case statement?

I don't know. How many times does that switch statement appear? If
it's once, then the difference between switch and polymorphism will be
similar, and a bit weighted towards the switch. If there are 11
instances of the switch statement, then the difference will be
dramatic and strongly weighted towards polymorphism.

Robert C. Martin (Uncle Bob) | email: unclebob(a)
Object Mentor Inc. | blog:
The Agile Transition Experts | web:

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Robert C. Martin on
On 20 Jun 2005 16:44:33 -0700, "coeval" <hvfrench(a)> wrote:

>When one says the main concept in OO is polymorphism, let me I have
>some doubts.
>I read lot of books about OO to improve my skills but most of the time
>the real world is completely different.
>I suggest OO authors and OO evangelists should dive in 100,000 lines of
>Java/C++ code, written by numerous OO-ish programmers, to fix bugs,
>defects, performance issues and misconceptions.

Been there. Done that. And with a *lot* more than 100,000 lines of
C++. And I say that the main concept of OO is polymorphism. Without
polymorphism OO is simply an argument between: f(o) and o.f().

Robert C. Martin (Uncle Bob) | email: unclebob(a)
Object Mentor Inc. | blog:
The Agile Transition Experts | web:

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
First  |  Prev  |  Next  |  Last
Pages: 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
Next: Use Case Point Estimation