If two modules A and B depend on each other, what does that indicate in ADP terms?

If two modules A and B depend on each other, what does that indicate in ADP terms?

• A. There is no cycle; this is fine.
• B. They must be merged into a single module.
• C. This is only a problem if both modules are concrete.
• D. A cycle exists between A and B.

Answer: (D)

In ADP terms, dependencies are modeled as a directed graph and they should form an acyclic graph. If two modules depend on each other, you’ve created a cycle: you can go from A to B and back to A. That cycle violates the principle and signals tight coupling that makes maintenance, testing, and evolution harder. So the correct interpretation is that a cycle exists between A and B. To fix it, you’d break the cycle by introducing an abstraction or reassigning responsibilities so dependencies flow in one direction (for example, both modules depend on a common interface or new shared module). The idea that there’s no cycle, or that you must merge them, or that the problem only matters if both are concrete, aren’t accurate because the cycle is the core issue here.

In ADP terms, dependencies are modeled as a directed graph and they should form an acyclic graph. If two modules depend on each other, you’ve created a cycle: you can go from A to B and back to A. That cycle violates the principle and signals tight coupling that makes maintenance, testing, and evolution harder. So the correct interpretation is that a cycle exists between A and B. To fix it, you’d break the cycle by introducing an abstraction or reassigning responsibilities so dependencies flow in one direction (for example, both modules depend on a common interface or new shared module). The idea that there’s no cycle, or that you must merge them, or that the problem only matters if both are concrete, aren’t accurate because the cycle is the core issue here.