Re: Confusion With Inheritance

H. S. Lahman wrote: 
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.

That's one view of development.. and it's rather platonic.. the idea that there are these concepts floating around out there independent of us. The issue I notice is that when people think those concepts are given, they don't explore alternatives, and often the "given" concepts aren't the best ones for software.

I am curious, though. I have a description of a language interpreter in this blog: http://www.artima.com/weblogs/viewpost.jsp?thread=120750

It's something I've been working on in my spare cycles. If you're game, I'd love to hear what the "problem space" is for my interpreter and whether I'd be screwed if I didn't use them in the work I'm doing.

Michael Feathers
www.objectmentor
.

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: 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. ... 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. ...
    (comp.object)