Re: OO Design induces an existential crisis

Let me get this straight... your argument is:

> Inconsistency is one of the biggest problems with OO today. There are
> no guiding design principles that anybody agrees on.

> Nobody can agree on when and what patterns to use.

1. There is no one way to do OO right

> This is why Visual-Basic, despite many flaws, kicked SmallTalk's MVC
> *** in the marketplace. SmallTalk had all the GUI wind and hype behind
> it, but was flattened by a better, simpler idea.

2. More people like procedural than OO.

> Procedural with a RDBMS has proven relatively simple, easy to learn,
> easy to relate to, easy to navigate, relatively consistent, and is not
> objectively worse than OO.

3. Structural programming and good data modeling is easier to understand and
when done well, is easier to maintain that bad OO code

You conclude: Using OO instead of Structured programming is not an effective
thing to do.

Did I miss any key points? I don't see any.

Let me address your key points:
1. There is no one right way to do OO.

The implication is that this is a weakness of OO programming, but not of
structured programming. Therefore, structured programming is better.

There are a dozen "right" ways to do Structured programming. They conflict
wildly because there are no real principles except encapsulation of
responsibilities in a module. I would challenge that the examples you
gave, for principles, are completely in alignment with the principles that a
developer followed when creating the code I am maintaining. That code is
frail. The coupling is very high and the cohesiveness is very low.
Maintenance is a nightmare. Your principles didn't lead this developer away
from that particular tar pit. Therefore, I would say that your principles
fall short of fulfilling the mission.

If I compare your principles to those described by Robert Martin, I'll go
with the latter. They, at least, make sense.

2. People prefer structured over OO.

Considering the fact that the vast majority of Visual Basic programmers have
switched to OO in the past few years, your argument loses credibility.
Smalltalk was crushed because no major software vendors, including
Microsoft, didn't back it. It offered no advantages over C++, and Java took
the attention of the OO world by storm. There was no reason to bother. It
had nothing to do with a simple idea. VB and Smalltalk were aimed at
different markets. VB's market was bigger. That's a triumph of marketing.
That has nothing to do with a comparison between OO and Structured
programming.

I would also say that, in 1905, people prefered horses over automobiles.
Preference at any particular time is not a good indicator of ultimate
success.

3. Structural programming and good data modeling is easier to understand and
when done well, is easier to maintain that bad OO code

I would say that anything, compared to bad code, looks good.

I would also say that good OO code, compared to good structured code, is
less expensive to create, maintain, and modify. It is easier to unit test.
Good OO code is easy to share and easy to navigate. Perhaps the problem is
that you have never seen good OO code? Can't blame OO for the lack of
training that others have had in it.

I would also say that good RDBMS principles can be applied equally well to
OO coding as to structured coding, and in fact, the concept under O/R
mappers don't work when you attempt to apply them to a structured
programming environment. This makes for more code to overcome the mismatch
between business objects and database tables.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.