What is the correct way to develop / implement two (or more) classes that have a "c" relationship to the same object?

Question

Suppose I have a design like this:

The object GUI has two objects: an aManager object and a bManager object that never talk to each other.

Both aManager and bManager have a cManager object as an attribute (or rather a pointer to cManager). Therefore, when aManager changes its cManager, it also affects bManager cManager.

My question is, what is the correct way to develop / implement it?

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

Is there a specific design pattern that I should use here?

Answer 1

I am going to interpret this as simple as possible if I do not answer your question, I apologize.

When you really get the answer to this question, this is your first step towards really thinking about the object-oriented level.

In OO, when two objects have an "object" zero, it’s quite acceptable for both references to this other object. The trick with OO is that the objects have their own life, they are fluid, and anyone who needs them can reference them. The object must remain "Valid" and maintain stability when used by many other objects. (That's why immutable objects such as String are so large they are ALWAYS valid, like the second they were created)

The only exception is if you are coding in C ++, because then you really need to manually free objects, which implies an owner who can control every life cycle of the object, which makes it really "difficult" to think in OO in C ++ .

[Addition] Since you are referencing pointers, I think you are programming in C ++, which is different. In this case, you are right. Make one Native manager the life cycle of your shared asset. It should not let this object die until all other links have disappeared.

You can also use reference counting. Whenever someone gets a reference to your object, he calls "addReference" or something like that, whenever this is done, the link is deleted. If someone calls removeReference when the counter is 1, the object can clear itself. This is probably so close that you can come to the true distribution / deallocation of OO-style in C ++. This is very error prone.

There are libraries that I believe do such things.

Answer 2

I recommend just passing cManager as a parameter to your GUI object constructor, but don’t maintain a reference to it (Java code is 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 do not think that singleton or Factory is suitable here.

Answer 3

Use singleton with caution (or don't want to at all if you need easy tests!)

• Singleton are pathological Liars
• Where are all the singles gone
• The root cause of the singleton

Answer 4

You can use the Factory template to request a link to cManager using both aManager and bManager as needed.

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

Answer 5

You should study the separation of your GUI with your model and implementation.

You can make cManager single, if only ever intended for one cManager, ever, in an application.

Answer 6

It is difficult to answer without discussing what you want to achieve. But, I would say go with getting a GUI to pass a pointer to aManager and bManager, as you say.

If you are trying to create a graphical interface and are wondering how to get data from and from it, 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 this is mostly written for C # users, but will apply to other languages. I guess this may be more advanced than you need for your first OO application. I think you will need to get a book on OO design and spend a few evenings there.

As a noob, I recommend that you don’t bother to do the most perfect right the first time, but just make something work. Over time, you will learn (and read a lot) that makes a decision better than others according to different criteria. There is no right answer to your question.

Answer 7

In general, at any time, any mutable object must have exactly one clearly defined owner (throughout the life of an object, an object usually has several owners, the first of which is a constructor, which then transfers ownership rights to the code that called it, etc.) d.). Everything that contains a link to an object should consider this link as a link to an object belonging to someone else.

You might think that when switching from C ++ to Java or .net, "Hey, cool - I no longer need to worry about object ownership," but that's not true. Ownership of mutable objects is just as relevant in a GC-based system as in a system without a GC. The absence of any means of expression of ownership does not relieve the programmer of the obligation to know to whom it belongs. It just complicates the fulfillment of this obligation.

If cManager is mutable, then either aManager should have it, or bManager should contain a link to it, and think of any changes in its purpose as influencing anManager cManager, or bManager should own it (using manManager containing the link, etc. ), or some other object must own it, with the help of manManager and bManager both think of their changes as affecting those belonging to this other object.

Even if you use a language or framework that does not recognize any concept of ownership, always think in such terms when dealing with mutable objects. To do otherwise is to invite confusion and disaster.