Resolving Dependency Cycles

Creating interfaces for classes as well as placing them in a certain component is not an end in itself. It creates extra effort and boilerplate code, which needs to be justified by some purpose.

So the first question you need to ask yourself here is: which purpose do you want to achieve? For example, unit testing is a typical goal. But unit testing alone the scetched classes does only require interfaces, not necessarily in separate components. Still, isolation at the component level can make testing more simple or faster or less costly, or it enables parallel development by different persons or teams. Hence you need to decide if you want the classes CA and CB testable in full isolation from each other, so tests for CA, which may need to implement a mock for CB using the interface IB dont even have to include the component B? Or is including the component B for a test cheap and hence acceptable?

If you think you need full isolation in both directions, none of your designs seems to be sufficient - for this, one will have to introduce extra interface components, either one layer for all interfaces, or an individual interface component for each interface. But beware, such a split-up causes extra maintenance effort, hence you should have a real need for it.

If in doubt, start with the most simple approach which serves your current needs (for example, everything in just one component), and refactor when you encounter requirements where separate components seem better suited.

Interfaces should be grouped with what owns then. Ownership is about what can force change.

If A uses B through I the real question is if you remove method call b.x() from A but not x() from B then what should happen to x() in I? Group I with the one whose changes it follows.

I call this ownership. An interface defines a communication relationship between objects. But that relationship is rarely symmetrical. Usually the interface either represents a using objects needs or an implementing objects mini language (at least one of them). The difference is which one can force I to change.

I’ve talked about this before here.

In C or C++, you can just declare a struct (or a class in C++). This gives almost no information about the struct or class, except that such a class exists. You can have pointers to struct or class instances and pass them around, and that's about it.

Now that is enough for example to just declare the existence of two classes C1 and C2, and then define them and note that an instance of C1 contains a pointer to a C2 instance, and an instance of C2 contains a pointer to a C1 instance. You can declare C1 methods that take pointers to C2 instances as arguments or return these pointers. You can do that because your compiler can compile your code without having the slightest idea what a C2 instance looks like.

In many cases this is enough to handle circular references. And it's often a good idea anyway. If C1 has a method that is given a pointer to C2 by a caller, and passes it on to someone else, C2 has no need to know the details of C2, so it shouldn't have knowledge of these details.

With interfaces, it is often the case that you know how interfaces are related, but not how classes implementing the interface are related. So if a class implementing I1 refers to I2, that's not a problem whatsoever. If you have circular references between interfaces themselves, you most likely have a more modern compiler which can handle it.