📑 Table of Contents▼

In software engineering, a circular dependency (or cyclic dependency) is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually recursive.

Overview

edit

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.

Problems

edit

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 automatic garbage collectors (those that use reference counting) from deallocating unused objects.

Causes and solutions

edit

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.

See also

edit

References

edit
  1. ^ a b Lakos, John (1996-07-20). Large-Scale C++ Software Design (1st ed.). Boston: Addison-Wesley. ISBN 9780201633627.
  2. ^ Melton, Hayden; Tempero, Ewan (2007-01-12). "An empirical study of cycles among classes in Java". Empirical Software Engineering. 12 (4): 389–415. CiteSeerX 10.1.1.141.5362. doi:10.1007/s10664-006-9033-1. ISSN 1382-3256. S2CID 11134940.
  3. ^ JDepend for Java

📚 Artikel Terkait di Wikipedia

Dependency injection

together, but must not be the client, as this would create a circular dependency. Because dependency injection separates how objects are constructed from how

Dependency hell

Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific

Dependency graph

because they are number literals. In a dependency graph, cycles of dependencies (also called circular dependencies) lead to a situation in which no valid

Domain Name System

requires resolving example.org first, which presents a circular dependency. To break the dependency, the name server for the top level domain org includes

Acyclic dependencies principle

common dependencies there. Package principles Circular dependency "Granularity: The Acyclic Dependencies Principle (ADP)" (PDF). Object Mentor. Archived

Directed acyclic graph

circular dependency, and is generally not allowed, because there would be no way to consistently schedule the tasks involved in the cycle. Dependency

List of software anti-patterns

Circle–ellipse problem – Problem in object-oriented programming Circular dependency – Problematic interdependence of software modules Constant interface

Spreadsheet

Recalculation generally requires that there are no circular dependencies in a spreadsheet. A dependency graph is a graph that has a vertex for each object