Re: Association vs Dependency

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/02/04 

Date: Fri, 02 Jan 2004 19:40:29 GMT

Responding to Gaab...

>>IOW, entire books have been written about how to handle physical
>>coupling at the OOP level and those techniques are often dependent on
>>the specific language.
>
>
> Yeah, like the one I am currently reading by J. Lakos. I think it is a good
> book but it is strictly dealing with C++.

Other books provide similar distillations. Riel's "OO Design
Heuristics" and, especially, Fowler's "Refactoring" address the same
sorts of concerns. The stuff in Lakos' book will usually apply to any
statically bound language that employs header files without a lot of
tinkering.

>
>
>>So it is superfluous to specify dependencies in
>>the OOD.
>
>
> That makes sense. So OOD is purely logical without any talk of physical
> units whatever they may be.

Right. There are no langauge-specific, compilable units identified in
the OOD. Even distributed boundaries are abstracted to subsystem or
layer interfaces and the introduction of objects responsible for
interacting with protocols (e.g., Jacobson's "interface" classes).

[In UML one can use the Component Diagram to describe the deployable
view of the application. That view may track to some degree with
compilable units but it is independent of the logical views represented
by Class, Activity, Statechart, and Interaction Diagrams and abstract
action language that describe the problem solution.]

>
>
>>Worse, it is actually subverting the prerogatives of OOP.
>
>
> How so? In your opinion then is C++, Java or Smalltalk instances of OOP.
> And that each instance may or may not implement features of OOP? Or they
> may implement features in terms of the flavor of the syntax used?

IMO, any time one is implementing an OOA/D in 3GL code one is doing OOP.
  Even in a procedural language implementation one must still thoroughly
understand the OOA/D constructs so one is still doing OOP. (I've
implemented OOA/D models in both C and BLISS manually.) The OOPLs,
especially those that are statically bound, just tend to have more
problems with physical coupling that procedural 3GLs. That's because
the compiler needs to generate code behind the scenes to support the OO
constructs and that code tends to have physical (compilable unit)
dependencies through the header file definitions.

[Lakos has some good discussions about that sort of coupling early in
the book, as I recall. In principle it applies whenever the logical and
implementation definitions are defined in the same physical place,
regardless of how well they are syntactically decoupled. IOW, for the
code writer they are decoupled but for the compiler they aren't.]

Basically I see the following division of concerns:

OOA -- the implementation-independent solution of functional
requirements. This is the customer's view of the solution if it were
implemented as a manual system (i.e., w/o computers).

OOD -- the strategic solution of nonfunctional requirements. This is
all the high level strategy stuff around caching, distributed
boundaries, stateless server objects, and the like.

OOP -- the tactical solution of nonfunctional requirements. This is
where one deals with CORBA vs. .NET infrastructures, SQL, state
expressed as XML, exception handlers, what sorts of collection classes
one employs to implement relationships with multiple participants, and
whatnot. In particular one deals with the vagaries of particular languages.

How physical coupling is manifested will depend on what the language de
jour is, so it is OOP's prerogative to deal with maintainability issues
like physical dependencies in the environment. IOW, when one identifies
a dependency in OOD, one is telling the OOP developer that it is
important and needs to be dealt with properly. But whether it really is
important may depend upon the language or infrastructures used. So it
should be up to the OOP developer to make those decisions rather than
the OOD developer.

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

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

Relevant Pages

  • Re: xp and simple design
    ... The market is currently swamped with OO-based modeling, ... > language; and use those abstractions to represent things in the real ... > dependencies flow between modules. ... > model of the solution in an OO language that has dreadful coupling ...
    (comp.object)
  • Re: Association vs Dependency
    ... OOPL features and OOP ... Dependencies are not even included in the OOA MDA profiles. ... coupling at the OOPL level. ... But that is a OOP issue, not an OOD issue. ...
    (comp.object)
  • Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)
    ... That greatly depends on the language. ... You have to *show* OOP being better, not merely claim you are smart ... I find at least two problems with OO's approach to "extension without ... It works for systems programming, ...
    (comp.object)
  • Re: why still use C?
    ... >> learn and work with with the C language, ... > - some people don't want to learn OOP ... can be used with many other programming styles. ... >> have caused him to associate your nonfluency with English ...
    (comp.lang.c)
  • Re: A new paradigm
    ... OOP being described in OOP language instead of in English. ... Many of us in the MV environment are business people who know what we are ...
    (comp.databases.pick)
Loading