Acyclic dependencies principle

File:Acyclic dependencies, circular dependency example.svg

In this UML package diagram, package A depends on packages B and C. Package B in turn depends on package D, which depends on package C, which in turn depends on package B. The latter three dependencies create a cycle, which must be broken in order to adhere to the acyclic dependencies principle.{{cite book | title=UML Distilled | first=Martin | last=Fowler | year=2004}}

Software dependencies can either be explicit or implicit.

Examples of explicit dependencies includes:

• Include statements, such as #include in C/C++, using in C# and import in Java.
• Dependencies stated in the build system (e.g. dependency tags in Maven configuration).

Examples of implicit dependencies includes:{{cite web|title=Implicit Dependencies Are also Dependencies|publisher=O'Reilly|url=http://programmer.97things.oreilly.com/wiki/index.php/Implicit_Dependencies_Are_also_Dependencies|accessdate=2013-06-16|archive-url=https://web.archive.org/web/20130525055437/http://programmer.97things.oreilly.com/wiki/index.php/Implicit_Dependencies_Are_also_Dependencies|archive-date=2013-05-25|url-status=dead}}

• Relying on specific behaviour that is not well-defined by the interface exposed.
• Network protocols.
• Routing of messages over a software bus.

In general, it's considered good practice to prefer explicit dependencies whenever possible. This is because explicit dependencies are easier to map and analyze than implicit dependencies.

It is in general always possible to break a cyclic dependency chain. The two most common strategies are:

• Dependency inversion principle
• Create a new package, and move the common dependencies there.

• Package principles
• Circular dependency

{{Reflist}}

Category:Software design