Re: OO Design induces an existential crisis

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

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

You asked about what "principles" OO can be guided, so that there is no
ambiguity. 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.

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

> 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

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

> (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.
I offer my sincere condolences.

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.

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


.