From: Robert Martin on
On 2008-03-17 19:14:20 -0500, kk_oop(a)yahoo.com said:

> Hi. I've got a question about "component" dependencies in C++. For
> this discussion, I'm considering a component to be a group of classes
> that implement a service provided to other components via an interface
> or via a service request message.
>
> Consider component A and B. B offers a service processWidget. This
> service is invoked by A sending a ProcessWidget message to B. The
> message is represented by the header file ProcessWidgetMsg.h.
>
> My directory structure is set up so each component has a root
> directory named after the component. So in this example, we have peer
> directories A and B. Under each of these directories are the
> respective component's implementation files or subdirectories
> containing implementation files. Let's say in this example, B has a
> subdirectory called WidgetProcessor and that contains various .h
> and .cpp files that know how to process a Widget.
>
> Here are my questions:
>
> 1. If I put a Messages folder under B and store the
> ProcessWidgetMsg.h file there, would you consider component A to be
> dependent upon component B? I'm thinking it would be, since A needs
> a .h file under B's file hierarchy (the ProcessWidgetMsg.h file).

Yes, A depends directly on B. If you make a change to that header
file, then A will need to be recompiled, and redeployed.

>
> 2. If instead of doing that, let's say I created a Messages directory
> as a peer to A and B, and I placed the ProcessWidgetMsg.h file there.
> Would you still consider A to be dependent on B, since A still
> requires B's service? I know there would be no physical dependency in
> this case, but would there be utility in documenting that A has a
> logical dependency on B?

A no longer depends directly on B. Rather A depends on the presence of
something that implements ProcessWidgetMessage.h. You might have many
different implementations. A needs one of them to exist, but does not
care which one. So A does not depend on B. Moreover, there is no
change you can make to B that will force B to be recompiled or
redeployed.

This is called "Dependency Inversion". See "The Dependency Inversion
Principle", http://www.objectmentor.com/resources/articles/dip.pdf


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



From: Lloyd Bonafide on
Robert Martin <unclebob(a)objectmentor.com> wrote in
news:2008040220224616807-unclebob(a)objectmentorcom:

> On 2008-03-17 19:14:20 -0500, kk_oop(a)yahoo.com said:
>> 2. If instead of doing that, let's say I created a Messages directory
>> as a peer to A and B, and I placed the ProcessWidgetMsg.h file there.
>> Would you still consider A to be dependent on B, since A still
>> requires B's service? I know there would be no physical dependency
>> in this case, but would there be utility in documenting that A has a
>> logical dependency on B?
>
> A no longer depends directly on B. Rather A depends on the presence
> of something that implements ProcessWidgetMessage.h. You might have
> many different implementations. A needs one of them to exist, but
> does not care which one. So A does not depend on B. Moreover, there
> is no change you can make to B that will force B to be recompiled or
> redeployed.

I assume you mean that no change can be made to B that will force *A* to
be recompiled and redeployed, no? And doesn't this assume that A and B
are not statically linked into a single executable?