Some design issues with C++

I have the following dilemma here: I have a few classes, let's say A, B, C and D. A has a public interface, and a has-a relationship with B (like A is having a member variable of type B) and one of the methods of A is returning this B object, B is just a class who exposes some methods, C is another class which exposes other methods, and D is a singleton object. The public interface of D has references (pointers if you like more) to objects of class C.

So, obviously when I want to draw a relationship diagram at this step, I would have a relationship between A and B and C would be put on the diagram, without visible relationship to the other two. So, this is based on the header (.h) files, which contain the declaration of class A, B, C. I'm a little confused about D right now.

On the other end:

1. both the implementations (in the .cpp files) of A and B are heavily dependent on objects created from class C (no, C is not something standard, such as list, string, queue, but another meaningful class in my application).
2. both the implementations of A and B use the开发者_如何学运维 D singleton with the local C objects.

And here are my questions:

1. What relationships should I put on the class diagram between A, B, C and D, not counting the one I have identified (A has-a B)? I'm particularly interested in the singleton D's relationship to class C.
2. What is the generally accepted methodology for this kind of situations (when the interface is not having relationships between objects, because there are none, but in the implementation they are heavily used)?
3. Would there be a difference if I would have the same question in accordance to Java and not C++ (because in java everything related to a class is in one file, so it's easier to see what a class method is actually using, while in C++ you usually just see the header).

Thanks a lot for your guidance.

Most of the information you provide should be recognizable in the following class diagram(plantuml input). I hope that answers the first question.

@startuml
class A
A o--> B
A : + method()
A : + B& getB()
A : - B m_B
A --> "getC" D 

class B
B : + method()
B --> "getC" D 

class C
C : + method()

class D <<Singleton>>
D --> "0..n" C
D : + C* getC( int index )
D : - list<C> m_containerOfC

@enduml

Regarding the second question: I think the point of drawing UML diagrams (I suppose for designing) is mostly about abstracting, hence ignoring details. There is no point in trying to express a complete C++ program in UML after you have written the program. You can buy programs that (attempt to) do that for you but I don't think these diagrams are useful.

The answer to your third question is that at a design stage the UML for a java and a c++ implementation should be equal, or at least for a large proportion. Designing is about choosing and connecting design patterns etc., and these are language independent. When you start detailing your diagrams to represent more implementation details (e.g. the type of containers used etc.) then the chosen language for implementation comes into play. However, at that stage you should ask yourself whether your diagram gives you enough confidence in your design and then start coding it.

You should definitively read the book Large-Scale C++ Software Design.

It particularly deals with the modeling of dependencies between interfaces and implementation, by introducing two new relationships uses-in-the-interface and uses-in-the-implementation, instead of just the traditional "has-a".

Then, it goes on with design principles applied to such modeling (such as isolation, insulation, encapsulation, etc.). It is really a highly technical book, though. So be prepared!