6

I recently found out that circular dependencies exist between some .Net assemblies from the following question and I'm looking for some explanation of why these exist:

https://stackoverflow.com/questions/43505621/circular-reference-in-net-assemblies

I've seen plenty of reasons to avoid circular references but are there any benefits? If not, then what is the historical reason of why these exist and why haven't they been cleaned up?

|improve this question
  • The most obvious answer is re-use. Re-using types means fewer types, but increases the risk of circular references. But actually encountering a circular reference in your own code should be relatively rare; the only way it's going to be a problem in your own code is if you include enough class references to actually create the circular reference locally. You don't have to compile the entire framework, so the circular references in the framework itself should normally be a non-issue for you. – Robert Harvey May 1 '17 at 21:27
  • It is not easy for anyone to compile using circular references, so I imagine it is a mistake. While you could say re-use is a benefit, the real issue is the packaging of types: if they reference each other that way, they should be in the same assembly. For historical reasons it is hard to fix that. – Frank Hileman May 1 '17 at 21:32
  • 4
    Library boundaries are strongly influenced by organizational boundaries in the business unit hierarchies which produce them. If the boundaries of two libraries seem strange then your best bet is to investigate the history of the political situation in the teams which produced them. I would start by examining this org chart: emuneee.com/blog/2012/11/12/microsofts-org-chart – Eric Lippert May 1 '17 at 22:53
  • 3
    As for why something did not happen: doing stuff costs money. Cleaning up this circularity is top of whose priority list when assigning budgets for the next fiscal year? My guess would be no ones. If its not in the budget, it doesn't get done. – Eric Lippert May 1 '17 at 22:55
  • So there isn't a benefit to this structure that couldn't have been achieved without a circular reference given the resources to refactor or prior planning? – Seth Denburg May 3 '17 at 13:57
4

I can conceive of only one benefit of having a circular reference, and even that is rather dubious: less libraries/modules. In order to resolve such a reference between two entities A and B, one usually needs to introduce a third entity C that contains whatever A and B need in common:

Resolution of circular dependencies

I think that circular dependency was introduced by mistake, and now it is too late to disentangle the libraries involved because, for example, it will break backwards compatibility through the relocation of some public classes or methods.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.