Circular dependency

In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly.

Overview

Circular dependencies are natural in many domain models where certain objects of the same domain depend on each other. However, in software design circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.

Problems of circular dependencies

Circular dependencies can cause many unwanted effects in software programs. Most problematic from a software design point of view is the tight coupling of the mutually dependent modules which reduces or makes impossible the separate re-use of a single module.

Circular dependencies can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects (program errors, compile errors). Circular dependencies can also result in infinite recursions or other unexpected failures.

Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors (those that use reference counting) from deallocating unused objects.

Causes and solutions

In very large software designs, software engineers may lose the context and inadvertently introduce circular dependencies. There are tools to analyze software and find unwanted circular dependencies.

Circular dependencies are often introduced by inexperienced programmers who need to implement some kind of callback functionality. Experienced programmers avoid such unnecessary circular dependencies by applying design patterns like the observer pattern.

Example of circular dependencies in C++

Implementation of circular dependencies in C/C++ can be a bit tricky, because any class or structure definition must be placed above its usage in the same file. A circular dependency between classes A and B will thus both require the definition of A to be placed above B, and the definition of B to be placed above A, which of course is impossible. A forward declaration trick is therefore needed to accomplish this.

The following example illustrates how this is done.

• File a.h:

#ifndef A_H
#define A_H

class B;	//forward declaration

class A {
public:
	B* b;
};
#endif //A_H

• File b.h:

#ifndef B_H
#define B_H
 
class A;	//forward declaration

class B {
public:
	A* a;
};
#endif //B_H

• File main.cpp:

#include "a.h"
#include "b.h"
 
int main() {
	A a;
	B b;
	a.b = &b;
	b.a = &a;
}

Note that although a name (e.g. A) can be declared multiple times, such as in forward declarations, it can only be defined once (the One Definition Rule).

Self-reference example

Following is another example of forward declaration, which might be useful if the application needs a self-sustaining array of objects which is able to add and remove objects from itself during run-time:

• File a.h:

class A {
public:
    static A *first, *last;
    A *previous, *next;

    A();
    ~A();
};

The static variables first and last have to be defined, because their declaration does not reserve memory space for them. Note: static variables do not change from object to object and stay the same for this given class.

They should also be initialized to 0, or NULL, so we know what they are to start with.

• File a.cpp:

#include "a.h"

A *A::first=0, *A::last=0; // don't put the word static here, that will cause an error

A::A() {
    if(first==0) first=this; //first A created
    previous=last;
    if(previous != 0) previous->next=this;
    last=this;
    next=0;
}

A::~A() {
    if(previous != 0) previous->next=next;
    if(next != 0) next->previous=previous;
}

External links

• The Circular Dependency Rule : Abstract definition as applied to Symbolic Model Verification language