Oo Is Just Good Engineering

Somebody should try to explain the title. Does it say that non-OO <=> bad engineering, and if you are a good engineer you'd better be doing OO ?

To succeed with OO, you must first become a good engineer. ;-)

That's true of just about any paradigm/technique/tool.

Ah, but it is not necessarily true to the same extent as for OO with its massive libraries of SoftwareDesignPatterns, brutish hacks for concurrency and persistence, issues with reference cycles, weak composability (cf. PrimitivesAndMeansOfComposition) et cetera. Not every paradigm is as badly conceived as OO. (AlanKay complains that OO evolved in the wrong direction - see AlanKayOnMessaging.)

There are no credible reasons to think OoHasFailed.

Has it succeeded? What are the agreed-upon BenefitsOfOo? Has it surpassed the alternatives, or merely become a peer?

It doesn't have to surpass the alternatives. OO is a tool, and like any tool, it's useful in certain circumstances. (Rest of discussion moved to WhenToUseWhatParadigm.)

Languages don't afford us the ability to easily switch paradigms. I would suggest that paradigms are closer to materials than tools. Cf. FallacyOfTheRightTool.

Oh? "The primary concern of the professional programmer is communication with the reader [of the program's text]." - Henry Ledgard, Professional Software vol 1.

OO is so bad for this, that all OO development environments include crutches -- class browsers and the like. We have to have crutches, because the code to do one meaningful-in-the-problem-domain thing is scattered. We should have had them long ago, but it was possible to get by, just. So the good thing about OO (or is that GUIs?) is that it forced acceptance of the use of tools to help one create programs.

The discussion immediately below is a bit academic. "Reusability" is a Hard Problem (and possibly not as important as all that), and OO is at best a very partial solution.

The way objects are supposed to have failed is in "reusability". Components are supposedly re-usable where objects supposedly are not. This distinction is just silly. Components are no more inherently re-usable than objects. It's hard to engineer for re-use properly with either. It's possible to engineer for re-use properly with either. Anyone who says different is selling something. If anything, it's harder to achieve reuse with components than it is with objects, because components are mostly just fancy widgets and GUI-sugar; they contribute almost nothing to reuse at non-GUI levels of abstraction.

Object orientation is good engineering not because of this reusability nonsense, but because it provides maintainability. OO makes your code easier to write OnceAndOnlyOnce. OO lets your code become self-documenting. OO allows you to connect your design concepts directly with your implementation entities. And OO permits you to re-use design and architectural patterns, rather than just syntactic idioms. OO permits you to design by contract, where components only permit design by cookbook.

That is quite a list of claims there. It might result in requests for illustrations or EmpiricalEvidence. "Self-documenting" is not one I hear mentioned often.

See Also: DnaVsOo.

Components are no more inherently re-usable than objects.

Unless we define -- as some people do -- components as units of reuse, in which case it is true by definition. I find this a useful definition, but of course it doesn't make it any easier to write reusable code. In particular, components are not necessarily graphical, and they're not necessarily even OO: in a few cases, a mostly-procedural interface is best. -- MartinPool

Not necessarily graphical, sure, but how many NonGraphicalComponents have you seen? DB interfaces, maybe. But your closing conjecture is pretty interesting. WhenAreProceduralInterfacesBetterThanOoInterfaces??

Booch's rule of thumb that you have to rewrite it for three different uses before it's reusable sounds true.

How could we disprove it? If it ain't falsifiable, it's voodoo.

By "sounds true" I meant "agrees with my experience". In the first cycle, YouArentGonnaNeedIt means that the component will be fairly specific to the way it is used; if it is a good abstraction then after it has a couple more clients it will be as general as is needed to serve its abstraction well. The point is not to shoot for complete generality in the first cycle (YAGNI), but to accept that you should pay for reuse over the first few cycles.

Re: To succeed with OO, you must first become a good engineer. ;-)

That's true of just about any paradigm/technique/tool. One should both know many design alternatives for the same given requirement(s), AND also know WHY they are choosing one over the other in a practical sense, not just dogma. (And sometimes it is a subjective decision; different designs fit or don't fit WetWare in different ways.) --top

"Good engineer" is ripe for gobs and gobs of LaynesLaw.

GenericLimits

CategoryObjectOriented?