Menu
First, I will describe an example of how this can happen using C# in Visual Studio, since VS will typically inform you if you have a circular reference and prevent it.
First, a Utilities class is created relying only on the code given to you by Visual Studio and .Net. Then, an E-mail class is created that depends on Utilities. Instead of adding both projects to a single solution, a new solution is created and a reference to Utilities.dll is added. Then, some time later, someone decides that they want the Utilities class to send an e-mail and adds a reference to Email.dll. Visual Studio is perfectly happy to let you do this, but now the source won't compile as-is without one of the binaries.
At my place of work it is standard procedure to copy-and-paste binaries when doing development and then only building the projects you're working on. This has led to at least one circular reference in the codebase that has gone unnoticed for over 3 years.
This seems like a very bad practice to me because there is no way to build either project from source without having the DLLs first. That argument falls a little flat to the "practical" people I work with since it seems highly unlikely that we will lose all copies of our binaries simultaneously. The binaries aren't stored in version control at any point, which only makes me more worried.
This seems like a situation that should be avoided, but not a situation that poses any appreciable threat. Are circular references between projects really a big deal or am I blowing it out of proportion?
298
Circular references are inherently fragile and easy to break. This stems partly from the fact that reading and understanding code that includes circular references is harder than code that avoids them.
Circular references aren't a bad thing in itself: you can use them to achieve complex calculations that are otherwise impossible to do, but first you must set them up properly.
Circular reference occurs when two or more interdependent resources cause lock condition. This makes the resource unusable. To handle the problem of circular references in C#, you should use garbage collection.
In and of themselves, circular dependencies are not a problem. However, what they point to - tight coupling - generally can be a problem. Essentially, by tightly coupling two classes you're accepting that a change in one is likely to result in a change in the other.
Yes, this is a bad practice for precisely the reason you've stated - you cannot rebuild from the source.
83
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
