|
From: Robert Martin on 2 Apr 2008 21:22 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 3 Apr 2008 08:00 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?
|
Pages: 1 Prev: [ANN] Spring 2008 Issue of Methods & Tools Next: How can I design\implement this |