Re: Confusion With Inheritance

Responding to Feathers...

Knowledge and behavior responsibilities have always been given equal stature in OO development. 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.

Defining objects based primarily around behaviors rather than the whole entity is just a form of procedural functional decomposition. One ends up defining a function library that collects procedures into classes rather than abstracting the problem space. Then when one connects up the class library with messages one has a C or FORTRAN program with strong typing.


I swear every time someone mentions concepts in the "problem space" I go blank. There are no concepts in the problem space other than those we put there and we can reconceptualize as we need to to make software development more effective.

Say what?!? The problem space is the domain where the requirements are formulated. Most customer problem spaces are quite conceptual with notions like Account, Arbitration, ..., Zone.

Those concepts certainly exist independently of software or software developers. At the OOA level a domain expert who knows nothing about software or the developer's solution should be able to describe what an object is and what its responsibilities are fairly accurately just from the name. If not, the developer has screwed up the abstraction.


*************
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
    ... 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. ... Defining objects based primarily around behaviors rather than the whole entity is just a form of procedural functional decomposition. ... One ends up defining a function library that collects procedures into classes rather than abstracting the problem space. ...
    (comp.object)
  • Re: string class with method approximatelyEquals(String s)
    ... > The hardest part of software development is not in telling ... analyses while I figure out what definition of "approximately equals" ... might be appropriate for this problem space. ... the analysis is being done by sorting and eyeballing the data (about ...
    (comp.lang.java.help)
  • Re: Confusion With Inheritance
    ... Defining objects based primarily around behaviors rather than the whole entity is just a form of procedural functional decomposition. ... One ends up defining a function library that collects procedures into classes rather than abstracting the problem space. ... At the OOA level a domain expert who knows nothing about software or the developer's solution should be able to describe what an object is and what its responsibilities are fairly accurately just from the name. ... I have a description of a language interpreter in this blog: http://www.artima.com/weblogs/viewpost.jsp?thread=120750 ...
    (comp.object)