From: Jeff Brooks on
topmind wrote:
>>>>Says the person who hasn't presented objective evidence
>>>>supporting his position.
>>>
>>>It is my opinion that paradigm preference is largely a *subjective*
>>>thing. Thus, there is not much to objectively prove either way.
>>
>>Then why do you keep asking for objective evidence from the OO guys?
>
> If you guys also believe the benefits of OO or poly are subjective
> instead of absolute, then simply say so and then we are done. That is
> not the message I get from youses.

"Making any claim about something being 'better' than something else
requires a way to measure 'better'. Currently we don't have a good way
to do it for the procedural vs OO debate so it's is nothing more than a
personal bias."
- Jeff Brooks - March 16, 2005 in comp.object
From: Isaac Gouy on
CTips wrote:
> What language are you using? Java? Out of curiosity, why isn't main in a
> class? Is this now legal in Java?


Nice => http://nice.sourceforge.net/

(compiles to jvm bytecode)


> > We get the same compiler error message as before (if we comment out the
> > intersect definition in test.rectangle).
> >
> > //--- separate file
> > import test.shape;
> > import test.rectangle;
> > import test.circle;
> > import test.intersect;
> >
> > void main(String[] args){
> > let r = new Rectangle();
> > let c = new Circle();
> > testIntersect(c,r);
> > testIntersect(c,c);
> > testIntersect(r,c);
> > testIntersect(r,r);
> > }
> > void testIntersect(Shape s1, Shape s2){ s1.intersect(s2); }
> >
> >
> > //--- separate file
> > package test.intersect;
> > import test.shape;
> > import test.circle;
> > import test.rectangle;
> > intersect(Circle s1, Rectangle s2){ println("circle rectangle"); }
> > intersect(Rectangle s1, Circle s2){ println("rectangle circle"); }
> >
> >
> > And if we run the program:
> >
> > I:\test>java -jar test.jar
> > circle rectangle
> > rectangle circle

From: Phlip on
Jeff Brooks wrote:

> topmind wrote:

> > If you guys also believe the benefits of OO or poly are subjective
> > instead of absolute, then simply say so and then we are done. That is
> > not the message I get from youses.
>
> "Making any claim about something being 'better' than something else
> requires a way to measure 'better'. Currently we don't have a good way
> to do it for the procedural vs OO debate so it's is nothing more than a
> personal bias."
> - Jeff Brooks - March 16, 2005 in comp.object

"Polymorphism sucks"

-Phlip, 2005 June 7, in news:comp.object


From: topmind on
> Having lots of small hierarchies that have HAS-A relationships is the
> normal way things are modeled in OO.

Well, that is a messy way, at least for me. Instead of multiple
hierarchies I find it easier to manage features as sets. Think of a
structure like this:

Instance 1: A, B, H, J
Instance 2: B, H, M, R
Instance 3: E, R
Etc...

Classes using inheritance or interfaces creates a data structure. One
can draw a graph (network) showing all the connections, similar to a
UML diagram. I would rather these relationships be put into a database,
or at least a data structure, so that I can edit, view, and browse them
from different perspectives, or at least code them in one spot.

I was spoiled by a nimble tool called dBase. Bash the language all you
want[1], but it made it so damned easy to create and browse tables that
I never want to go back to using program code as a data structure
beyond simple trees (in outline format).

But even without a nimble table tool, one can still create lists,
associative arrays etc., to deal with the web of relationships.

If the "structure" is simple, it does not make much difference whether
OO or case statements or whatever is used. The differences are small.
But if it gets complex, then it is usually better to treat it as a data
structure. Code is too damned hard to read when it contains a hidden or
hard-to-isolate tangled graph, at least for me. If you can easily read
such speghetti, I applaud you. But us mere mortals need view-alterable
data structures to better manage the speghetti. Make the machine do the
work, not the human. That is what automation is all about.

[1] It indeed had some ugly flaws, but what it did well it did well.

-T-

From: topmind on
> Classification hiearchies don't need to be used to model everything in
> OO. Your argument in this case is very weak.

Yes, but OOP is ugly when you diverge from trees, as described in a
nearby reply. It loses its "innocence" and becomes messier than the
alternatives when you go beyond trees in OOP.

OO was sold to the IT world using simple, easy-to-navigate hierarchies
and their close cousin, sub-typing. But the reality is far uglier. The
IT world has been victimized by bait-and-switch advertising. You wander
outside the world of shape and animal examples and......well, you've
seen the movie Truman?

-T-
oop.ismad.com

First  |  Prev  |  Next  |  Last
Pages: 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Next: Use Case Point Estimation