[
Lists Home |
Date Index |
Thread Index
]
> You're obviously thinking of objects purely at the coding level.
Funny, I read things the other way. I took Len to mean "type" in the
informal sense, as in "what type of car is that" and read your note as
using it in the more formal compsci sense, as in "what is the type of that
variable"
> You don't
> have to. The essential notions of separation between interface and
> implementation scale up.
Agree.
> So do notions of encapsulation, delegation, and
> type hierarchy (though perhaps not implementation-level inheritance).
It seems to me that the first two are implementation matters. But more
importantly, type hierarchy doesn't seem to scale. Your payroll example
seems to make every service an object. Can you take that example further
and describe some other kinds of objects that might exist? And show the
hierarchy?
OO architectures are decomposition into type hierarchy and often try to
make an object's location (is it local or remote) unimportant. The unit of
work is the method.
SOA architectures are decomposition into interfaces and generally assume
that the two parties aren't colocated. The unit of work is the message.
/r$, who really should know better than to join this thread
--
SOA Appliances
Application Integration Middleware
|
