Re: Confusion With Inheritance

Responding to Martin...

Notice that when you described your classes, you described them in
terms of the data that they held, and not in terms of the behavior
that they exhibited. This is the first, and most serious, problem
with your example. Object Oriented Design is a discipline for
partitioning *behavior*, and *incidentally* the data that goes with
that behavior.

We disagree Big Time on this one. 


Actually, I doubt that we do.  From the outside an object is nothing
but a bundle of behaviors.  We might infer that there is some data
inside the object, but we can't be clear on exactly what data that is,
what form it takes, and where that data is actually located.

We specify abstract /properties/ for objects. The OO paradigm supports exactly two sorts of properties: knowledge responsibilities and behavior responsibilities. While the knowledge responsibility implementation is hidden by an ADT (and in fact it may not be implemented with a data store at all), it is nonetheless a basic property of the abstraction that we define.


Some of the behaviors of an object present data at the interface.
Those behaviors might just be simple accessors, or they might be much
more complex operations that just appear to be simple accessors.

That's the OOP view biased by the procedural nature of 3GLs. In OOA/D behavior is treated quite differently than knowledge. For example, one assumes a synchronous access for knowledge properties while one assumes an asynchronous access of behavior properties because message generation and method response are separated in both the diagrams and the abstract action languages.


This view decouples the data itself from the behaviors.  When we look
at an object, we know what it *does*, but we don't exactly know where
it does it.


Per the above, we also specify what it /knows/.

Knowledge and behavior responsibilities have always been given equal stature in OO development.


In relation to procedural development there was a definite shift.
Data was made private, and behaviors were grouped into scopes
(classes). 

In any class, the behavior is public but the data is private.  I'm not
talking about C++ keywords here, I'm talking about the general
principles.  Data is hidden and behavior is exposed.  This is almost
precisely the opposite of a data model in which data is exposed and
behavior is absent.

Both knowledge and behavior /implementations/ are hidden. But both sorts of properties are explicitly identified to describe what the object /is/.


I'll grant you that data is *part* of OO development, but from a
stature point of view, data is the black sheep ugly child that is
hidden away into a closet when company comes over.

Only for someone who has been in the 3GL muck too long and is mapping procedural paradigms onto OO development. B-)

One abstracts the /intrinsic/ properties of problem space /entities/. The proportions of knowledge vs. behavior or their relative importance to the solution is not relevant -- one abstracts and encapsulates the entity's bundle of relevant properties as the object.


Granted. This is why I think we don't disagree on this topic. The
data is not the motivation for creating object partitions. It is the
behavior of the object that defines its boundaries and the
partitioning strategy.

One cannot define class membership without defining what knowledge responsibilities the entity has.

entity X has a behavior responsibility encapsulated as a doIt method along with a weight attribute.

entity Y has a behavior responsibility encapsulated as a doIt method along with a height attribute.

Those entities cannot belong to the same class because their knowledge properties are different even though they both provide exactly the same behavior. The only way to model those entities as related would be via:

          [EntityXY]
          + doIt()
               A
               |
      +--------+---------+
      |                  |
   [EntityX]        [EntityY]
   + weight         + height

Defining objects based primarily around behaviors rather than the whole entity is just a form of procedural functional decomposition. 


Not at all.  Functional decomposition is the breakdown of function
into a hierarchy.  (e.g. a calling tree).  Object oriented
partitioning is a breakdown of behavior into responsibilities that
have relationships with one another.  That's a very different type of
decomposition.

The technique tended to be hierarchical because one reduced the level of abstraction at each level. However, in the end one had flat sequences of atomic <sub>operations from the functional decomposition. One then identified sequences of those operations that were repeated and organized them into procedures. That's the paradigm I am talking about -- organizing program structure around predefined sequences of operations. One only got the tree if one recognized sequences of the procedures and cobbled them together for even higher level procedures.

One ends up defining a function library that collects procedures into classes rather than abstracting the problem space.


Incorrect. Responsibility Driven Design (Wirfs-Brock) is one of the
oldest and best methods of partitioning the problem domain into
objects; and does not lead to a functional decomposition.

And the point is? Hers is an OO methodology. Wirfs-Brock acknowledges knowledge responsibilities as a fundamental part of the definition of an object role. From her latest book, "Object Design: Roles, Responsibilities, and Collaborations", pg. 3:

"A Responsibility = An obligation to perform a task or know something"

Seems like pretty clear distinction and equal stature to me.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Confusion With Inheritance
    ... >Knowledge and behavior responsibilities have always been given equal ... partitioning strategy. ... >entity is just a form of procedural functional decomposition. ... >rather than abstracting the problem space. ...
    (comp.object)
  • Re: Design problem
    ... I can of course have enums representing types of operations and have some ifs in the circle construct but this fails the LSP. ... abstraction (which, in turn, is driven by the subsystem's subject matter ... behavior responsibilities into more manageable atomic responsibilities ... graphics rendering, physics, etc. ...
    (comp.object)
  • Re: implementing roles in OOP......
    ... >>must be clearly related at the level of abstraction. ... "An application implements a system of responsibilities. ... > either the car itself or a factory. ... If some client needed to collaborate with the properties of Wheel, ...
    (comp.object)
  • Re: object system...
    ... in order to use abstraction as self-target. ... Note that an object is defined by its responsibilities. ... never have an interface to access not doing something. ... The 3GL type systems are a compromise with the hardware computational models. ...
    (comp.object)
  • Re: Structured programs (long)
    ... knowledge responsibilities and don't live by the same rules as behaviors. ... subsystem level of abstraction, it can be a scalar attribute, named ... FPLs bring functional abstraction (and often syntactical abstraction, ... eliminating hierarchical dependencies. ...
    (comp.object)