What is the correct way to design/implement two (or more) classes that have "has a" relationships with the same object?

Question

Suppose I have a design like this:

Object GUI has two objects: object aManager and object bManager, which don't ever talk to each other.

Both aManager and bManager have object cManager as an attribute (or rather a pointer to cManager). So when aManager modifies its cManager, it's affecting bManager's cManager as well.

My question is what is the correct way to design/implement this?

I was thinking of making cManager as an attribute of GUI, and GUI passes a pointer to cManager when constructing aManager and bManager. But IMHO, GUI has nothing to do with cManager, so why should GUI have it as an attribute?

Is there a specific design pattern I should be using here?

Answer 1

You can use the Factory pattern to request a reference to cManager by both aManager and bManager as needed.

http://msdn.microsoft.com/en-us/library/ms954600.aspx

Answer 2

You should look into separating your GUI from your model and implementation.

You could make cManager a singleton if there is only ever meant to be one cManager ever, app-wide.

Answer 3

This is tricky to answer without a discussion about what you want to achieve. But, I'd say, go with getting GUI to hand the pointer to aManager and bManager as you say.

If you're trying to create a GUI and wondering how to get data in and out of it, then I can recommend this: http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx

I think that is mainly written for C# users, but would apply to other languages. I'm guessing this may be more advanced than you need for your first OO application though. I think you're going to have to get yourself a book on OO design and spend some evenings with it.

As a noob, I recommend you don't bother trying to do everything the most perfect correct way first time, but just get something to work. You'll learn with time (and reading a lot) what makes a solution better than others for different criteria. There's no right answer to your question.

Answer 4

I'm going to interpret this as simply as possible, if I'm not answering your question, I apologize.

When you really get the answer to this question, it's your first step to really thinking Object Orientedly.

In OO, when two objects both "has a" 'nother object, it's perfectly acceptable for both to refer to that other object. The trick with OO is that objects have a life of their own, they are fluid and anyone that needs them can keep a reference to them. The object must keep itself "Valid" and maintain stability when being used by many other objects. (This is why immutable objects like String are so great, they are ALWAYS as valid as the second they were created)

The one exception is if you are coding in C++ because then you actually have to manually free objects, that implies an owner that can monitor each object's lifecycle--that makes it really really hard to "Think" in OO in C++.

[Addition] Since you are referring to pointers, I'm thinking you are programming in C++ which is different. In that case, you are right. Make one manager "Own" the lifecycle of your shared object. It must not let that object die until all other references have gone away.

You can also use reference counting. Whenever someone gets a reference to your object, it calls "addReference" or something, whenever it's done it removes the reference. If anyone calls removeReference when the count is 1, the object can clean itself up. That's probably as close as you can come to true OO-style allocation/freeing in C++. It's very error-prone though.

There are libraries to do this kind of stuff I believe.

Answer 5

I recommend just passing in cManager as a parameter in your GUI object constructor, but don't maintain a reference to it (Java code here, but you get the idea):

public GUI(CManager cManager)
{
    this.aManager = new AManager(cManager);
    this.bManager = new BManager(cManager);
    // don't bother keeping cManager as a field
}

I don't think either a Singleton or Factory is appropriate here.

Answer 6

Use singletons with care (or not at all if you want easy tests!)

• Singletons are Pathological Liars
• Where Have All the Singletons Gone
• Root Cause of Singletons