[
Lists Home |
Date Index |
Thread Index
]
Yes, I am. That is precisely the viewpoint where that description
belongs.
Ever try to sell that to a retail manager? I get the rolling eyeballs
everyday at my job from the sales manager who wants to sound smart but
not too smart. No one buys from a guy who intimidates on the first
pass. Here in geekDom, we are comfortable with smart people. The other
95% of the world isn't. We scare them.
Again, I didn't say it was precise, I have been careful to note the
nature of attributed semantics, and I've been careful to explain the
concepts of viewpoints and proximity to situation semantics. I have
also refuted your challenge that 'service architecture' is a root
concept that subsumes all others so meaningless because
indistinguishable.
If it is re-branding, aka, same old wine in a brand new bottle, then it
is the same as XML, the same as 'metaverse', the same as most of the
'new inventions' which make up this "unpredictable astounding and
innovative" web that grinds out myths and heroes as a byproduct of it's
imperial ambitions. (How's that for begging the question? HA! :-).
Re-branding concepts for mass consumption is the key to stealing from
the middle. It gets rid of the old guys who are trouble, substitutes
the more manipulable new guys, and redirects the revenues from the
original inventors to the posers and their bosses. It makes the
customers feel smart and in the know. As long as the concepts translate
reasonably tightly to the means of implementation, they are useful,
meaningful and appropriate for the tasks at hand. If we are going to
gloss over complexity, let's get our story straight.
Computers, objects, and interfaces are just stuff. To buy a product, a
customer must look into the brochure, and as in a mirror, see their own
face. The service concepts work well for that purpose. If the
ontology is coherent, it is a straightforward effort to transform from
that mental scaffolding down to any of a number of implementation means
of which, OOP is one. The very last thing one wants to attempt when
selling a computer architecture is to teach the customer computer
science. One may want to make them believe they are learning that just
as HTMLers were taught to believe they were programming when building
web pages. After a time, they were, but in the beginning, it was just
markup and links. Ever since that time, this has been the way of the
web.
"As the twig is bent..."
len
From: Michael Kay [mailto:mike@saxonica.com]
> I'd say that was what you were trying to implement, not what
> you were attempting to specify. How could you create an
> object-oriented program without the implementation?
You're obviously thinking of objects purely at the coding level. You
don't
have to. The essential notions of separation between interface and
implementation scale up. So do notions of encapsulation, delegation, and
type hierarchy (though perhaps not implementation-level inheritance).
A company that provides payroll services is an object in a business
architecture; it's an instance of a type, which can be substituted by
other
instances of the same type; it holds encapsulated data; and its internal
implementation is hidden behind an interface. The service it provides is
not
just defined by a functional interface, but by quality metrics including
performance, availability, security, and potential for change. Just like
code objects.
Michael Kay
http://www.saxonica.com/
|
