Re: OO Design induces an existential crisis

Nick Malik [Microsoft] wrote:
> >>
> >> The comments that you are quoting are not the principles that I spoke of.
> >>
> >> Please see
> >> http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfObjectOrientedDesign
> >>
> >
> > Those are mostly shown in terms of systems software and device drivers.
> > I have already conceded that domain may do better under OOP (but am not
> > an authority of that domain so cannot fully comment).
>
> This statement makes me believe that you either didn't read the articles
> linked from that page or that you didn't understand them. I can only
> conclude that you either criticized what you did not read, or you read them
> and misunderstood them and then mischaracterized here.

I don't necessarily even disagree with them. I just cannot evaluate the
change pattern frequencies assumed in the articles because I have
insufficient experience with that domain. I have not seen too many
techniques that don't have tradeoffs. However, without the ability to
weigh the probability of each change path, it is very difficult to see
if those techniques really do reduce the impact of change in systems
software.

>
> Principles of OO have everything to do with business programming, and all
> other forms of programming when OO constructs are used.

Good. Show it improve the change-handling of *business* examples then.

There must be a good reason why OO training examples roughly have a
ratio of 25-to-1 in favor of sys software examples over biz examples. I
have read articles about others complaining about OO and the business
domain. Thus, I am not the only one who has raised the issue.

There is a problem somewhere. Can you explain this odd ratio????

>
> You asked about what "principles" OO can be guided, so that there is no
> ambiguity.

The ambiguity is in the change patterns they assume and test. You
cannot hide from probability. I can even give change scenarios that is
more code rework in the device driver examples.

Nobody has questioned that in such debates that I remember. In other
words, nobody has ever disagreed with the suggestion that a given
design cannot weather ALL changes better than the competition.

If you agree with this, then you must agree with me that probability
plays a role. That is, we pick the design that reduces the change
impact of the (estimated) most *common* changes.

Clear?

I didn't see anything from you or RM that appears to suggest otherwise.



> I gave you a link to a well-described set of them. Now it is
> your turn. Send me a link to a single set of well described and well
> documented structured programming principles.

Those are Robert Martin's principles, not necessarily *general* OO
principles. My website is full of similar kinds of examples in roughly
the same detail as RM's. I even explore a version of his modem-driver
example.

>
> (let's see if you can find one)
>
> >
> > Are there any OO gurus out there who want to take on custom business
> > applications? Any?
>
> DAILY

I mean write about them and give examples of OO kicking
procedural/relational's ***.

>
> I am an application architect working with Microsoft's internal IT divisions
> to solve business problems typical of any large multinational corporation...
> mine just happens to develop software. The problems I work on, however,
> have little to do with the cycles of commercial software development.
>
> I use OO to solve business problems.

Assembler can be used also. That does not make it better.

>
> > The few biz justification examples I've seen still beleive in
> > hierchical taxomies to manage variations of biz objects.
>
> Bad programmers make bad code. That isn't the fault of OO

It seems that OO'ers tend to be bad proceduralists/DB'ers. Thus,
perhaps they are abandoning p/r because they suck at it, not because of
any inharent fault in it. We won't know with more certaintenty if this
is the case without public code comparisons.

>
> You and I agree that a hierarchical taxonomy of variations is nearly always
> a bad use of inheritance.
>
> > That is a
> > no-no. The real world in general does NOT change in a hierarchical way.
>
> we agree about this

Good, this simplifies the debate.

>
> > (We already had a huge debate about this last month. Nobody presented
> > good open evidence for trees, only anecdotes and intimidation) And if
> > you don't use hierarchies, OO gets rather messy.
>
> It is messy only if you are a structured programmer mis-using object
> oriented techniques. Some heirarchies are necessary, and occasionally
> useful, but they often subtract more than they add. A heirarchy that is
> more than three levels deep (e.g. has great-grand-children) is probably ripe
> for refactoring, except in very rare situations.
>
> You have convinced me of one thing: you have never seen OO done correctly.
> Therefore you are convinced that it cannot be done.

No! I am only saying that public evidence does not exist. Yet companies
are spending zillions on OO. So quick to spend without any real science
or comparative analysis? No so bright. Even the ACM has at times
decided to steer clear of paradigm comparisons and endorsements because
they are not happy with the science attempted to compare.

> I offer my sincere condolences.

I don't want condolences, I want comparative code examples.

>
> However, you can change that situation. You don't have to just live with
> bad code.
>
> Start with a very readable book: Design Patterns Explained by Shalloway and
> Trott. You can do what others failed to do. Even if you choose not to use
> OO, you will at least be speaking from a position of understanding. That
> will make your words much more convincing.

No, what is lacking is JUSTIFICATION for them, not explanations.
Procedural/relational has patterns also. The existence of patterns
alone does NOT make something better.

Let's see you show OO patterns being better outside of systems
software. Can you do it, or are you just another elusive
brOOchure-mouth?

The format should look something like:

Here is the OO code:

blah blah blah...

Here is the procedural/relational equiv. code:

blah blah blah...

Here are 5 change scenarios:

1. asdfasf...
2. adfasdfasdfsd...
3. asdssdf.....
4....
5....
(with possible frequency estimates)

Here are the scores for each scenario:

Number of lines changed: ...
Number of blocks changed: ...
Number of named-units changed: ...

Got Science?

>
> --
> --- Nick Malik [Microsoft]
> MCSD, CFPS, Certified Scrummaster
> http://blogs.msdn.com/nickmalik
>
> Disclaimer: Opinions expressed in this forum are my own, and not

-T-
oop.ismad.com

.