Re: Confusion With Inheritance

On Thu, 25 Aug 2005 17:39:42 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:

>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.

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.

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.

>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.

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.

>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.

>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.

>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.


-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.

Relevant Pages

  • Re: distorted model! do i need patterns or something!?
    ... When an activity in the customer space is such ... it as a major problem space responsibility that corresponds to the ... That decision will depend on what is most suitable to the problem in hand (e.g., what other responsibilities the underlying problem space Entity might need to solve the problem in hand). ... But at the OOA/D level it is conceptually quite different that either [HotelManager] or. ...
    (comp.software.patterns)
  • Re: Creating a "toy" OO/AO language...
    ... The OO paradigm abstracts problem space entities in terms of responsibilities to do something and responsibilities to know something. ... The FP paradigm just addresses one sort of side effect related to the global state variables of traditional procedural development with immutability. ... // do something involving the invocation of funcB ...
    (comp.object)
  • Re: Havent done anything real with OOP yet.
    ... >seriously complicated and developing an OO simulation would be ... >responsibilities to objects. ... >problem space in an OO fashion. ... >simplified to the same level of abstraction as the simulation assumptions. ...
    (comp.object)
  • Re: How to apply (rather than understand) OO?
    ... I don't know what books you've been reading about the OO paradigm, but the good OOA/D books will spend a lot of time walking you through problem space abstraction. ... and an object customer from that class, ... Identify individual responsibilities that those objects have _in the problem space_ that will be required to solve the problem. ...
    (comp.object)
  • Re: OO Unit Test Question
    ... A and B should be peer objects that are linked by a relationship rather than having B instantiated within A's implementation and they should collaborate normally. ... But if B abstracts a problem space entity, then other entities than A may need to collaborate with its responsibilities. ... then to avoid breaking encapsulation and implementation hiding those responsibilities now become A's responsibilities. ... But that is unnecessary effort because it just gets back to where one should have been in the first place with good problem space abstraction. ...
    (comp.object)