# Unity Solving internamespace and dll issues...

This topic is 4142 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello Community, I'm having some namespacing issues. Every namespace has it's own project in my engine, and therefore, gets exported into a separate dll. However, some of my classes are causing circular dependencies. For example, I have a class Point, which obviously stores a point in screenspace. This typically applies to graphics, which has it's own namespace Graphics. This would go into the project exporting the graphics api. The graphics project is dependent on the base project. But if I feel that a given class should be a part of the base class but requires the Point class, I'm stuck. How can I resolve these internamespace conflicts? Thanks for any assistance[smile], Chad Seibert

##### Share on other sites
I would say: how can a point be considered as a graphic entity? In mathematics, a point has no size - only a position. That hardly make it a graphic entity. Pixels have position too, but they also have other intrinsic data - such as the color, for exemple. So a pixel is not a point - it has coordinates, which can be represented as a point.

So my advice is to put mathematical entities in they own namespace - that sounds more logical anyway.

More generally, the idea to resolve this kind of namespace circular dependencies is to think about abstraction. Robert C. Martin published an interesting article about Design Principles and Patterns (here, PDF) and a chapter in this article is directly speaking of your issue (and how to handle it) (chapter "Acyclic Dependencies Principle"). In fact, the whole article is worth a read, so I encourage you to give it a look.

Best regards,

##### Share on other sites
Thanks for your reply, that article did provide some very good insight on engine development. However, this seems to be overly complicated for something as simple as a point. Is duplication of small classes terrible?

Thanks[smile],

##### Share on other sites
Quote:
 Original post by Chad SeibertIs duplication of small classes terrible?

It's worse than terrible. What happens when you update the class in one namespace and forget to update it in another? Very bad idea.

##### Share on other sites
I'm having a hard time abstracting away a point class. I see how I can create an abstract interface as a base, and implement it across namespaces's. However, for very simplistics structures like a point, which can be defined as:

struct Point{unsigned int X, Y;}

it seems to be overkill by a long shot. That's why I asked whether code duplication for small classes and structures is terrible or not. This 'Point' class could be defined in a different namespace, and typedef'd in the most logical one for use outside of the engine. For example:

namespace EngineImp{struct PointImp{unsigned int X, Y;}}//Now define it in Engine::Mathtypedef PointImp Point;

Maybe I'm not seeing the real picture here, but is this such a terrible way to deal with cross namespace duplications?

Thanks for the great advice[smile],

1. 1
Rutin
38
2. 2
3. 3
4. 4
5. 5

• 11
• 9
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633350
• Total Posts
3011473
• ### Who's Online (See full list)

There are no registered users currently online

×