Will cyclic namespace harm my design

I don't know if this is stupid question...

I have namespace

1. Core.Player.Behaviour
2. Core.Player
3. Core.Manager

1. have some classes reference at 2.
2. have some classes reference at 1.
1. & 2. are no reference in any direction with 3.

Would this example be a bad software design.

 

Not necessarily. Namespaces are really only used to group classes together into functional areas, and to keep global namespaces from being overfilled, or to separate identically named classes that have different functions (especially useful if you are using third-party libraries).

If it works for you (or your team), then organize away.

 

I think the general rule is that devs should be able to use everything in "Core.Player" without also needing to add "using Core.Player.Behaviour" as well. So having a class in Core.Player that internally uses a class in Core.Player.Behaviour is fine, but having a public function in a class in Core.Player that returns a class that is only in Core.Player.Behaviour is considered bad, because then that means the person using it is forced to add both using statements to make sense of their code.

Edit: However, I might just be making that up completely. This is just based on what I've generally seen in API's, I don't know if there's a real rule.

 

While it is not necessarily a bad practice to introduce circular references in namespaces I would try to avoid them as it might make refactoring a nightmare. Say you want to extract code from the Core.Player.Behaviour into another assembly all together, then you'll have circular references in Assemblies, which is a big problem (and impossible to do).

If you have specific classes that are used by multiple other namespaces, always try to group them logically.

For example, for a website I made I used the following main namespaces (assemblies):

• Project.Web (frontend logic, includes Project.Web.Controllers, Project.Web.Models etc.)
• Project.Business (business logic, includes Project.Business.Providers, Project.Business.Services etc.)
• Project.Data (data access logic, includes Project.Data.Entities, Project.Data.Repositories etc.)
• Project.Core (contains core logic, includes Project.Core.Dtos, Project.Core.Interfaces etc.)

Basically the references above are that all namespaces in Data are only used by Business, Business is only used by Web and Core can be used by all three other namespaces (assemblies). Basically I use the same separation within the assemblies. So a top level (Project.Data class is generally never called in lower level logic (Project.Data.Dtos). If I do need some class in those lower levels, it generally gets it's own namespace (and folder).

 

Yeah.. consider how often you see something like:

Code (csharp):

1. namespace Project.Code.Pathfinding { // I just picked a random example
2.     public class Pathfinder {
3.         public List<PathfindingNode> GetNodesFromPath(Path path) {
4.             // .. do some stuff
5.         }
6.     }
7. }

Now, to use our Project.Code.Pathfinding.Pathfinder.GetNodesFromPath(...) you have to use System.Collections.Generic. This isn't too big of a hassle. A good IDE will automatically suggest the namespaces to import, or give you a list of potential matches.

 

Someone needs to tell Microsoft that, then.

If you 'use System;', you still need to 'use System.Collections;', and maybe even 'use System.Collections.Generic;'

But something in S.C.Generic doesn't require the earlier two use statements necessarily. Again, there isn't anything particularly antithetical to using nested namespaces for organization.

 

Considering all three namespaces you use do very different things. I would be very dissappinted if they all automatically included the others. Last thing I'd want is my auto complete lists being filled up with every single thing from every single child namespace of system every time I just wanted to throw in a System.DateTime.

I generally try and avoid circular dependencies. They tend to make the code brittle and difficult to change. And given the nature of software development, brittle code is a bad thing.

 

I wasn't saying that nested namespaces are bad; I was saying that having a function within "System" return a class defined in "System.Collections.Generic" would be bad. I don't think Microsoft does that, at least not very often.