Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)


"topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message
news:1174848412.482369.286550@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

adaworks@xxxxxxxxxxxxx wrote:
"topmind" <topmind@xxxxxxxxxxxxxxxx> wrote in message

That greatly depends on the language.

The fact that something _can_ be done in a given manner
does not mean it _should_ be done that way.

Everybody on the web claims or implies they are Einstein's superior.
You have to *show* OOP being better, not merely claim you are smart
and experienced. Use code and realistic change scenarios applied to
it, for example. If you don't want to do it, then just say so. We
don't need yet more unverifiable anecdotes, they are a cheap commodity
on the web, to be frank. People come to see evidence, not read resumes
from people who have very positive views of themselves.

The evidence is the many software systems, including business
data processing systems that have been developed successfully
using OOP. Of course, there are also a lot of such systems
where OOP was used badly.


I find at least two problems with OO's approach to "extension without
modification".

The first is that most changes in the real world are *not* tree-
shaped. Overriding subtypes generally assumes a tree-shaped extension
pattern. (OO does not have to use trees, but it is far messier than
the competition, at least not better, when it does such.) I find sets
a better way to manage variations/features than trees and believe this
to be an inharent advantage of sets. They are far more flexible and
don't force you to commit to one dimension/factor being artificially
dominant. Trees may be okay in the short-term, but as more features
are piled on, they cannot handle it.

I think I mentioned Eiffel as a good model for doing OOP right. In
Eiffel, one is not restricted to the usual tree approach. Even so, levels
of abstraction do work well in real life. In Ada, a language that I
have found useful, the object model is augmented with a feature of
child library units that are a lightweight form of programming by
extension that does not require the standard model of inheritance.

Object components are not restricted to tree structures. And, message
passing via delegation does not depend on inheritance. Another powerful
variation is genericity. While this is not found in every OOP language,
it is an essential feature of Eiffel, Ada, Java, and C++ (as templates). I
admit that the template model of C++, while quite powerful, is also
full of potential for making a horrid mess of things. But this same feature
in Eiffel and Ada is a stable and effective adjunct to the object model.
There are a lot of variations for design in OOP that go beyond
inheritance alone.

The second is granularity. Real-world changes often don't always fit
the grain of one's code granularity. Thus, in practice one has to do
things like figure out how to override one-third of a method. It can
be a lot of code-rework to do such. And IF statement is like a
calliper that can reach over any range in any part of the code, and
this is less subject to granularity problems and less code re-work.
(If there is a pattern to many of the IF statements, then often such
can be tablized to make it easier to see and manage.)

Overriding, done correctly, does not require the code rework you
speak of. The principle is "open to extension but close to modification."
It works quite well in practice. It works for systems programming,
applications programming, and other kinds of programming. The one
exception, in my experience, is scientific programming where it seems
to have more limited application (limited is not the same as none).

I've pointed this out before, and don't remember you responding.

Tables are a good technique for software development. I have used
decision-table languages and I'm quite fond of the EVALUATE statement
in COBOL. I wish more languages had a statement similar to the
EVALUATE statement. I also use tables in other parts of my designs.

An IF statement, when doing extensible designs, requires one to revisit
existing implementation code, open it up (like cracking open a chest for
open-heart surgery), and modify it. This is not necessary in a correctly
designed OOP system. It violates the principle of "open to extension,
while closed to modification." I breaks the principles of information
hiding and encapsulation.

Further, an IF statement with the kind of global range you suggest is in
violation of the principles of coupling and cohesion. OOP has the
virtue of providing a stronger model of encapsulation, greater opportunity
for cohesion, and limiting the need for excessive coupling.

ADT are a nice concept on paper, but often just don't work in the real
world. They cannot handle reality very well.

This statement, by itself, flies in the face of a reality that has existed
since the early 1970's. It demonstrates a sad lack of understanding
of the central tenets of software development that have worked for
over thirty years. I recommed you read John Guttag's PhD dissertation
for a more comprehensive understanding of the concepts of data
and procedural abstraction.

Richard Riehle


.

Relevant Pages

  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (comp.lang.asm.x86)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (alt.lang.asm)
  • RfD - Object Extensions
    ... While there is general agreement that Object-Oriented Programming (OOP) ... Forth currently has no standard extension for this. ...
    (comp.lang.forth)
  • Re: Can a low-level programmer learn OOP?
    ... I have also found some articles profoundly critical of OOP. ... If it does, you'll find it easier, else choose another programming style. ... Starting in 1999 I got back into programming, but the high-level-ness of PC programming and the completely foreign language of OOP repelled me. ... Dynamic languages like Smalltalk, Python or Ruby are much more lightweight in this area, and tend to favor a much more exploratory style - sketch a quick draft on a napkin, start coding, and evolve the design while you're coding. ...
    (comp.lang.python)
  • Re: why still use C?
    ... >> learn and work with with the C language, ... > - some people don't want to learn OOP ... can be used with many other programming styles. ... >> have caused him to associate your nonfluency with English ...
    (comp.lang.c)