   Structure question
  I have a design question:I have a project with 2 important classes, A and B, and many other classes (lets say C, D, E, etc).Let's say C,D,E... want to use B.  Specifically, they want want to use a function that should return a data type from A.  However, they should not know about A, so, they cannot know about the return type.  (So you know what i have in mind, I am talking about opengl's Gluint which is just an unsigned int).  How can I shield them from A?I thought at first I could use a typdef, but, I forgot that the typedef would need to know about Gluint.  What can I do?Sincere regards,J   
Quote:Original post by Esmo2000I have a design question:I have a project with 2 important classes, A and B, and many other classes (lets say C, D, E, etc).Let's say C,D,E... want to use B.  Specifically, they want want to use a function that should return a data type from A.  However, they should not know about A, so, they cannot know about the return type.  (So you know what i have in mind, I am talking about opengl's Gluint which is just an unsigned int).  How can I shield them from A?I thought at first I could use a typdef, but, I forgot that the typedef would need to know about Gluint.  What can I do?Sincere regards,JI really don't understand this.If a class needs to call a membert function of B which calls A's member function then the return type of A's member would be the same of the return type of B. Therefore would class C not know the return type of B which is the same type as returned by A?;  I probably use an Interface to Class B in Class C that calls a function/s that doesn't have the return type of Class A. If you have to use the return type, then I agree with AP, class C should know about class A.   ;  I'd say "huh" [smile]If you call a function and don't care about the return value, why do you put a return value in the first place? Just don't do it and your problem vanish.Now, there is still a problem you can't avoid: if B has a function that returns a value of type A, everyone who knows B also needs to know A since A is necessary to understand the interface of B. I don't see much problem in this - if A has to be known by B because of its interface, any user of B might also have to know A because it may use it. If you really believe that there is somtheing very wrong with this then there is a problem in class B - it probably does too much things (which is a clear and savage destruction of the single responsability principle). In this case, refactor to remove the offending functions and put them in anotehr class. HTH,   ;  Despite what the others have said, what you want to do is perfectly reasonable -- it's called a "wrapper".Anyway, the solution is simple. Before returning the value from B, convert it to a value and type that C,D,E... can use.In your case, it is straightforward, but in general it can be problematic because you may be forced to lose information in the conversion (information directly associated with A).For example, if A returns an error code, then B can convert it to generic number, but the number no longer has any meaning as an error code. To solve this, you might convert A's error code into a related error code specific to B, but that could create unwanted coupling or result in ambiguity.   