How truly "evil" are cyclic namespace dependencies within a single assembly. I understand using multiple assemblies changes everything and something like that wouldn't compile, but what is the real risk of doing it within a single assembly?
+2
A:
No risk at all - feel free to reference anything you want within the same assembly.
However this approach will make you application brittle and hard to scale. A better approach is to try and keep your components as orthogonal as possible.
What the language and compiler allow you to do is not necessarily what is best for long-term developments needs (bug fixes, scaling, new features, etc.). You ought to strive for loose coupling and high cohesion.
Andrew Hare
2009-05-11 01:21:38
Understood, but I am only talking about a few instances where using something like separated interface is just not warranted and would be overkill.
2009-05-11 01:28:52
Then in that case I don't believe you have anything to be concerned about :)
Andrew Hare
2009-05-11 10:15:33
+1
A:
namespaces are a way to provide a logical organization to your code. They provide a way to reuse names by applying it within a certain context. There is nothing wrong with having classes in two namespaces depend on each other.
Cyclic depedancies in assemblies is a bit more complex. Last I checked visual studio wouldn't allow this type of relationship directly.
JoshBerke
2009-05-11 01:23:57
+1
A:
I don't think there are any risks per se, and in some cases it's certainly the natural way of doing things. System.Text.StringBuilder obviously uses System.String, and I'd be very surprised if nothing in the System namespace used StringBuilder in turn.
It's probably worth just checking your design every so often: question whether you should be able to separate the functionality into separate components. Quite often the answer will be "no", at which point just move on with no feeling of guilt :)
Jon Skeet
2009-05-11 05:31:20