Circular dependency – is there a good design to eliminate

circular-dependency

I was writing some code and came across a scenario that I was thinking about doing a circular dependent class, which I have not done before. I then looked circular dependencies up and whether they are impermissible, and found that it is achievable but not desirable. But I have some dilemma regarding how to implement it without circular dependencies so I thought I should see if there are other suggestions available.

Imagine that you are building an index for a number of files, and those files have a number of attributes, including an attribute that records what files the particular file references.

Attempting to set up some classes mimicking such structure, I have written a number of classes.

subClassA includes defining attributes of a file, let's call this
attribute set A
subClassB includes classification attributes of a file, let's call
this attribute set B
fileObject is an object representing a file, and has one
subClassA object and one subClassB object.
fileSet is an object representing a particular set of files, and
is essentially a collection of fileObjects

As I was creating subClassB, I realized that the information related to reference files within subClassB is really just a simplified fileSet with limited subClassA information. Is it wise then to simply circular reference within subClassB a fileSet object? Or if that is a terrible idea, how should one go about storing the information? Technically, we can create another collection class object under fileObjectthat will store a bunch of subClassA objects, but I don't really favor that as I would need to duplicate certain functions of fileSet within that new class definition (for example, functions that checks those objects, combines those objects, and etc).

And if I do it where I have an object_M that includes a collection of subClassA and another object_N that includes a collection of subClassB (that has an object_M included), and a top level fileSet that includes one object_M and object_N, that will solve the problem, but we suddenly got a new problem of needing some way to link the objects within object_M and object_N together somehow, another complexity in itself.

With the given scenario, should I just go with circular dependency? Or is there a better way to do it altogether?

Best Answer

Circular relationships exist in the world, so if your object model is to accurately reflect such a relationship, the model must have circular logical relationships as well. There is nothing wrong with this.

The issue arises in the case of circular references, as a matter of implementation, not design. An object graph that cycles unto itself may have issues with the language's disposal mechanism, e.g. in the COM universe, which uses reference counting, the objects will never dispose, resulting in a memory leak.

The simplest way to avoid this is to use identifiers instead of object references. For example, instead of

class FileSet: List<File>

You might use

class FileSet : List<int>

class File
{
    public int UniqueID { get; }
}

And then give each File instance a unique integer identifier. When you need to find the files themselves, you can use the identifiers to select them via their identifier (e.g. as an index into an array) rather than by an actual memory reference. This design will never have circular object references-- because there are no object references to begin with.

As long as you take care of the implementation details diligently, there is absolutely nothing wrong with circular logical dependencies in your design.

Related Solutions

Java – Proper Way to Model Real-World Activity with Circular References in OOP

I've been wrestling with a problem in a Java project about circular references.

Java's garbage collector doesn't rely on reference counting techniques. Circular references do not cause any kind of problem in Java. Time spent eliminating perfectly natural circular references in Java is time wasted.

I coded this up [...] but the problem is that it's full of circular references. I implemented it back then by stuffing all the intertwined classes in a single source file, [...]

Not necessary. If you just compile all the source files at once (e.g., javac *.java), the compiler will resolve all forward references without problems.

Or should I stick with the interdependent classes and coax the compiler into compiling them somehow, [...]

Yes. Application classes are expected to be interdependent. Compiling all Java source files that belong to the same package at once isn't a clever hack, it's precisely the way Java is supposed to work.

Circular Dependency – How to Solve Circular Dependency in Object-Oriented Design

Technically, you can resolve any cyclic dependency by using interfaces, as shown in the other answers. However, I recommend to rethink your design. I think it is not unlikely you can avoid the need for additional interfaces completely, while your design becomes even simpler.

I guess it is not necessary for a ReportGenerator to depend on a TestScenario directly. TestScenario seems to have two responsibilites: it is used for test execution, and it works also as a container for the results. This is a violation of the SRP. Interestingly, by resolving that violation, you will get rid of the cyclic dependency as well.

So instead of letting the report generator grab data from the test scenario, pass the data explicitly by using some value object. That means, replace

   reportGenerator.setTestScenario(ts);

by some code like

reportGenerator.insertDataToDisplay(ts.getReportData());

The method getReportData needs to have a return type like ReportData, a value object which works as a container for the data to be displayed in the report. insertDataToDisplay is a method which expects an object of exactly that type.

This way, ReportGenerator and TestScenario will both depend on ReportData, which depends on nothing else, and the first two classes do not depend on each other any more.

As a second approach: to resolve the SRP violation let TestScenario be responsible for holding the results of a test execution, but not for calling the test executer. Consider to reorganize the code so not the test scenario accesses the test executer, but the test executer is started from outside and writes the results back into the TestScenario object. In the example you showed us, that will be possible by making the access to LinkedList<Test> inside of TestScenario public, and by moving the execute method from TestScenario to somewhere else, maybe directly into a TestExecuter, maybe into a new class TestScenarioExecuter.

That way, TestExecuter will depend on TestScenario and ReportGenerator, ReportGenerator will depend on TestScenario, too , but TestScenario will depend on nothing else.

And finally, a third approach: TestExecuter has too many responsibilities, too. It is responsible for executing tests as well as for providing a TestScenario to a ReportGenerator. Put these two responsibilities into two separate classes, and your cyclic dependency will vanish again.

There may be more variants to approach your problem, but I hope you get the general idea: your core problem are classes with too many responsibilities. Solve that problem, and you will get rid of the cyclic dependency automatically.

Best Answer

Related Solutions

Java – Proper Way to Model Real-World Activity with Circular References in OOP

Circular Dependency – How to Solve Circular Dependency in Object-Oriented Design

Related Topic