Circular dependency

Circular dependencies are natural in many domain models where certain objects of the same domain depend on each other.[1] However, in software design, circular dependencies between larger software modules are considered an anti-pattern because of their negative effects.[1] Despite this such circular (or cyclic) dependencies have been found to be widespread among the source files of real-world software.[2] Mutually recursive modules are, however, somewhat common in functional programming, where inductive and recursive definitions are often encouraged.

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.

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.[3]

Circular dependencies can be introduced when implementing callback functionality. This can be avoided by applying design patterns like the observer pattern.

Implementation of circular dependencies in C/C++ can be a bit tricky, because any structure or class 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 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).

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

    A();
    ~A();
};

#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;
}

• Acyclic dependencies principle
• Dependency hell