RE: OOP and object models
- -----Original Message-----
From: Paul Prescod
To: Mathews, Walden
Cc: Bill de hÓra; Toivo "Deutsch" Lainevool; firstname.lastname@example.org
Sent: 12/4/2002 8:43 PM
Subject: OOP and object models
Mathews, Walden wrote:
>> Terminology strikes again. Object models and object oriented"behaviour" part of Identity, State, Behaviour. Objects carry around
> programming have separate lives, according to what I read. Bill
> is talking about polymorphic method resolution, which is one
> feature of OO (the programming thing), while Paul's description
> of "identity, state and behavior" is the /sine qua non/ of the
> object model.
>I've always seen polymorphism as being the core feature of the
their behaviour. Structs, XML documents, RDF graphs and other "pure data
structures" do not.
Yes, I shouldn't have said "polymorphic", strictly speaking. Jump
tables are about dispatching to some method in a code inheritance
hierarchy, and it's something we can ignore if we're mainly interested
in runtime behaviors and properties, a la software architectures.
Certainly the idea of different "shapes" lurking behind a single
abstract interface is a 'behavioral' concept, not a code reuse one.
> I suspect that the problem you have with the services style is thatIck, terminology is being misused. OOP is a programming structure
> it constitutes a collection of antipatterns for distributed OOP. If
> so, let's document what the risks of that style are.
paradigm dependent on such things as classes and inheritance. There
is no such thing as distributed OOP. Object-based systems is what you
get when you take OOD and distribute the objects. It is called
object-based (instead of object-oriented) because we are talking
about architecture, rather than source code structure, and architecture
doesn't have classes and inheritance.
> CommunicatingThat is difficult to do. The OOPSLA community took the architectural
> to the OOP world through patterns/antipatterns is a great way to
> make the case for the REST style - with the added bonus the claims
> for REST will seem less grand.
concept of patterns and expanded it into anything with a recipe for
implementation. I use the original notion of patterns, which came
from Alexander watching human behavior as people live/work/move within
a space. The closest analogy in computing is how data moves within an
architecture. In other words, I do explain REST as a pattern, but
what people call patterns now is tuned more for programming idioms
rather than understanding system behavior.
Architectural styles and architectural patterns are fairly consistent,
but as you noted the purpose of REST is to force the developer into a
less object-specific architecture, which is contrary to most of the
OOD patterns. Whether that is good or bad depends on what is
Roy T. Fielding, Chief Scientist, Day Software
2 Corporate Plaza, Suite 150
Newport Beach, CA 92660-7929 fax:+1.949.644.5064
Co-founder, The Apache Software Foundation