Sign in to follow this  
Chad Seibert

Unity Solving internamespace and dll issues...

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 this post


Link to post
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 this post


Link to post
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],
Chad Seibert

Share this post


Link to post
Share on other sites
Quote:
Original post by Chad Seibert
Is 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 this post


Link to post
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::Math

typedef 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],
Chad Seibert

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this