Circular dependency can create many redundant effects in software programs. The very first among them in terms of design is the tight coupling between mutually dependent modules, which results in reusing an individual module becoming more difficult or impossible. In general, there are several reasons why you should avoid circular references between objects. It creates the following problems:

• No dependency hierarchy and no reusability: Generally, we quantify the code with the layer it is at; for example, high level, low level, and so on. Every layer should only set a dependency (if any) on the layers below it. Normally, when you define dependency between modules, a dependency graph or hierarchy will be created, but in the case of a circular dependency situation, this will be eradicated. This means that there is no dependency hierarchy. For example, say you have the following dependency hierarchy:
  • Module A depends on module B
  • Module B depends on module C
  • Assume that, at present, module C has no dependencies

Based on this arrangement, we can identify module A as the top level, module B as somewhere in the middle level, and module C as the lower level of the hierarchy. Let's say that, after some time, we need to make module C dependent on module A (for whatever reason).

When this happens, there is no more differentiation between the high, middle, and low levels, which means that there is no longer a hierarchy. All modules are at the same level. Also, since they are in a circular dependency, they are no longer independent. This situation forms a single giant virtual module, which is divided into interdependent pieces. You cannot use any of them independently. 

• Changing replication: Circular dependency creates a ripple effect of changes. For example, if any change happens in one module, this may impact other modules, which results in undesirable effects on the overall software architecture, such as compilation errors, and logical program errors. Due to its nature, circular dependency may create other unpredictable issues, such as endless recursion.
• Readability and maintainability: Code that has a circular reference is naturally harder to understand and read than code that doesn't have a circular reference. Such code is intrinsically delicate and easy to breach. Ensuring that your code is free from circular dependencies will make the code easy to work with and make the code be able to accommodate changes with ease, resulting in easy maintenance. From a unit testing point of view, code that has a circular dependency is more difficult to test since it can't be isolated.