Re: Why is OO Popular?
From: Eric Kaun (ekaun_at_yahoo.com)
Date: 05/11/04
- Next message: Pete Smith: "Re: UML Tool Advice"
- Previous message: Robert C. Martin: "Re: inheritance question"
- In reply to: Michael N. Christoff: "Re: Why is OO Popular?"
- Next in thread: Cristiano Sadun: "Re: Why is OO Popular?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 11 May 2004 15:44:50 GMT
"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message
news:UqAnc.5291$FH5.207930@news20.bellglobal.com...
> Come on. You're saying OO has no better support for components than
> functional languages or structured languages? And note: modules <>
> components.
I understand that, and stick by my assertion. I'll change my tune if you
give me a good argument - in what way does OO provide better support for
components? My argument that it doesn't is based on the typical need for the
external component interface to support different languages (meaning that
you can't just hand out serialized Java objects, for example), and that most
components provide stateless interfaces which amount to little more than a
collection of conceptually-related functions.
Of course, since component is such a fuzzy and overloaded term, I could be
wrong.
> > The most active protocols are not OO in the least. And the work
> > required to "bake" objects from the byte streams moving around are for
the
> > convenience of processing in the language of the target component, not
for
> > any other reason.
> >
>
> I disagree. Encapsulated objects with interfaces (note I didn't mention
> inheritance) are the foundation of distributed systems.
Just because the various components are implemented using OO doesn't speak
to the importance of OO in distributed systems - all it means is that the
most common languages are OO ones. That says nothing about whether or not OO
supports components and distributed systems better than non-OO paradigms.
> Whether you
> implement the idea of "autonomous nodes in a network with private local
data
> that communicate by passing messages defined by interfaces" with
functional
> or whatever is not the point.
Yes, that's exactly the point.
> The point is that OO has direct support for this basic idea and the other
options do not.
What direct support? Point to it, name it, describe it, whatever.
> > The public doesn't know to ask for that, and the development community
> > doesn't either. Don't mistake acceptability (especially after a long
> period
> > of growth in the computing industry, which brings in many more people
and
> > requires spoon-fed education) with technical credentials. People are
> willing
> > to do a lot of stupid things.
>
> So you're essentially saying "noone knows". So how do you know that OO is
> not the best model? Note: I'm not saying it is (although I _believe_ it
> is).
I was obviously exaggerating, but
> > And it is - at least relational, not procedural. And from the point of
> view
> > of integrating services / interfaces across non-OO protocols and
> > heterogeneous systems, procedural is just as good as OO. What makes OO
> > better in such a case? It's commonly used in distributed compuing
because
> OO
> > is popular - not because it's ideally suited for it.
> >
>
> ** -
> I totally disagree. The idea of 'objects', be they actual implementaions
> found in a particular OOPL or more abstract notions, are the foundation of
> non-shared memory message-passing distributed architectures. They are the
> simplest way to think about such architectures as far as I'm concerned
since
> there is almost a 1-1 mapping from object to network node,
Wrong - are you really serious? Half the J2EE patterns are based on ways of
> from network
> message to object method invocation, and from local private state to
> encapsulation.
So you use exclusively stateful component frameworks? Most of us use
stateless, and when you're in stateless territory, there ain't no
encapsulation of state. In HTTP the state is passed back and forth - in rich
GUI - to - EJB architectures, the state is client-side. There are
exceptions, of course, but if object state were such a natural fit to
components, you wouldn't have the vast majority of J2EE users hiding their
entity beans behind stateless session bean facades.
> > Embracing complexity is to be avoided. Simplicity should be embraced.
> > Complexity should only be tolerated where you have no choice in the
> matter.
> > To embrace complexity is to spread your legs for any "design" which
> happens
> > by.
> >
>
> A design should be as simple as possible, but no simpler. Often the
> simplest solution is complex.
I disagree, but this is slippery to argue either way. The complexities arise
out of a focus on procedural (even within OO) and product-focused designs,
and out of insufficient design.
> Dijkstra? That stuff, while very important, is out of date.
hahahahahahahaha - you kill me.
> ie: although
> Dijkstra may have been the first to mention the idea of self-stabilizing
> systems, I would not recommend people read him to get the state of the art
> in this area.
Couldn't disagree more - the state of the art these days is precisely that:
art without logical foundation. It's a feel-good collection of practices
that he formalized years ago, but because formalism is "out", it doesn't
sell.
> About models: Almost all papers in distributed computing
> rely on either combinatorial graph theoretic models, or more recently,
> higher dimensional geometric models that employ techniques from algebraic
> topology.
True - these are researchers looking to impress, and of course their work
will make its way in some fashion into mainstream products, albeit in a
mangled form, since industry tends to take research, adopt some of its
lingo, do a half-assed implementation, and then pile on sellable features
that sound good but would be easier if they hadn't abandoned the foundation.
It's happened with process models, with relational, with industrial
engineering in general, with every methodology, etc. etc.
> I would agree that they are moving away from purely logic-based
> models (like the various predicate calculi for concurrency etc...).
Symbols
> are still very important in distributed computing, and are even making a
> come-back in general dynamical systems theory through the use of
statistical
> methods.
Statistics? Fun. We haven't even mastered the deterministic and static
models yet.
My point is this: there's a gulf between common practice and research, and
in particular solid research from years ago never makes its way into
products, and the focus on products infiltrates everyone's brain, resulting
in ability to comprehend design only through product comparisons.
> > Yes, and these are well-studied by a few, and ignored by most. I agree
> with
> > your observations, but to assume that we're in any way addressing them
> using
> > OO is nonsense. OO is around because it's around and useful for some
> things,
> > but like XML, it's now the proverbial hammer for the computing nail.
>
> Again, I believe that the 'object concept' is the simplest way to model
such
> systems. One can immediately see how we can take a network of nodes and
> turn it into collaboration between objects.
That's assuming you know what the nodes are - you're presupposing a
component design (or object - depends on the architectural tiers you're
mentioning). Prior to that, there are many ways to slice it, and many
possibilities that get ignored because of a premature commitment to objects.
And besides, I seldom do designs with networks of nodes. They're around, of
course, but design at such a high level presupposes the existence of member
systems that meet certain criteria for interoperability. And those criteria
aren't OO criteria.
> > Illusion is the right word. Don't get me wrong - it can be useful for
> human
> > communication. But like everything the RUP (also from Rational), it
adopts
> a
> > kitchen-sink approach, stuffs everything on (and inside) the pizza, and
> then
> > expects coherence to emerge. At best, it's a toolkit, not an integrated
> > approach to anything.
> >
>
> I tend to agree. However, I think the basic premise has merit, even if
its
> not a silver bullet.
Right, nothing is. I would just like to see some formal notation actually
get automated - that's what computers should be good for. You state the
invariants, the engine enforces 'em - it's a basic notion every framework is
built on.
- erk
- Next message: Pete Smith: "Re: UML Tool Advice"
- Previous message: Robert C. Martin: "Re: inheritance question"
- In reply to: Michael N. Christoff: "Re: Why is OO Popular?"
- Next in thread: Cristiano Sadun: "Re: Why is OO Popular?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
