When working within a single project that contains multiple namespaces, should these namespaces be treated as boundaries? Or is it acceptable that any namespace can access any other namespace?
For example, say I have the following namespaces in a project called Physics
- Physics.Models
- Physics.Math
Say in this case that some Models use classes defined in Math, and Math uses classes defined in Models. Is this an acceptable solution? Does there need to be some hierarchy to the namespace names that indicates dependencies? Something like
- Physics.Math
- Physics.Math.Models
Are there rules that should be followed? Or is this just left up to the developer to make smart and pragmatic decisions about relationships within a single project?
-
1Try to keep the dependencies acyclic as you can, so more like layering than mutual dependences. However, this is often not possible for foundational concepts, so don't sweat it.Erik Eidt– Erik Eidt2018年08月15日 22:07:54 +00:00Commented Aug 15, 2018 at 22:07
1 Answer 1
The short answer is that no there are no rules and its up to the developer as shows by the fact that the language itself doesnt care how you go about dealing with namespaces.
That being said, the way that you split up your namespaces, if you use them at all, falls down to the way the rest of your project is divided and what you(and your team) decide is the best way to address it. For your example, I would personally go with your first approach becasue it better communicates the use of the items in the namespace, but that is to me and may well not be the way someone else sees the namespace nomenclature.
tl;dr No, the language doesn't care, and it's a stylistic choice you'll have to make yourself