Using existing object when using New?

[Christopher D. Wiederspan]

This is a bit tough to figure out the best way to ask, but here it goes.
I've got a class, say MyObject, and everytime this class is instanciated, I
actually want to get a reference to an existing object. Maybe better stated
by example:
public class SomeClassA {
MySpecialObject A;
public SomeClassA() {
this.A = new MySpecialObject ();
A.FireSpecialEv ent();
}
}

public class SomeClassB {
MySpecialObject B;
public SomeClassB() {
this.B = new MySpecialObject ();
this.B.SpecialE vent += new System.EventHan dler(this.B_Spe cialEvent);
}
private void B_SpecialEvent( object source, System.EventArg s e) {
// Do something here...
}
}
So, the trick is, that I want both MyObject's A and B to reference the same
object, so that when the line "A.FireSpecialE vent()" is called, it will
trigger the event handler in the SomeClassB object (assuming that the
constructor for SomeClassB has already been called). My problem up to this
point is that since A and B are actually referencing different objects, the
events don't fire across (of course).

Any ideas would be greatly appreciated. I'm hoping there's a way to maybe
override the 'new' method or something so that both A and B will end up
referencing the same object instance...? Or maybe there's a whole better way
to do this with some sort of global Event mechanism that I don't know about.

Thanks,
Chris

[Brendan Grant]

Design patterns can be your friend and from the sounds of it... the Singleton
Pattern is exactly what you are looking for (shame it is the only one I know
well).

Take a look at this writeup over on MSDN on how it works:
http://msdn.microsoft.com/library/de...onInCsharp.asp

This example does not show exactly how to do what you are looking for...
however modifying it’s example into what (I think) you want will be a piece
of cake.

Brendan
"Christophe r D. Wiederspan" wrote:

This is a bit tough to figure out the best way to ask, but here it goes.
I've got a class, say MyObject, and everytime this class is instanciated, I
actually want to get a reference to an existing object. Maybe better stated
by example:
public class SomeClassA {
MySpecialObject A;
public SomeClassA() {
this.A = new MySpecialObject ();
A.FireSpecialEv ent();
}
}

public class SomeClassB {
MySpecialObject B;
public SomeClassB() {
this.B = new MySpecialObject ();
this.B.SpecialE vent += new System.EventHan dler(this.B_Spe cialEvent);
}
private void B_SpecialEvent( object source, System.EventArg s e) {
// Do something here...
}
}
So, the trick is, that I want both MyObject's A and B to reference the same
object, so that when the line "A.FireSpecialE vent()" is called, it will
trigger the event handler in the SomeClassB object (assuming that the
constructor for SomeClassB has already been called). My problem up to this
point is that since A and B are actually referencing different objects, the
events don't fire across (of course).

Any ideas would be greatly appreciated. I'm hoping there's a way to maybe
override the 'new' method or something so that both A and B will end up
referencing the same object instance...? Or maybe there's a whole better way
to do this with some sort of global Event mechanism that I don't know about.

Thanks,
Chris

[Bruce Wood]

I think that what you want is the Singleton pattern. Grab a copy of the
Gang of Four (Design Patterns by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides), or surf to Jon Skeet's page on Singleton
in C#:

http://www.yoda.arachsys.com/csharp/singleton.html

Essentially, what you want is to make MySpecialObject a singleton, so
that you say:

MySpecialObject A = MySpecialObject .Instance;
A.FireSpecialEv ent();

and elsewhere

MySpecialObject B = MySpecialObject .Instance;
B.FireSpecialEv ent();

and both A and B are the same object instance.

[Christopher D. Wiederspan]

Actually, I've already looked at this design pattern, and it would be what I
need except for this: I'm being lazy and MySpecialObject is actually a class
that inherits from Component, so it shows up in my Toolbox when designing
Windows Forms. My goal was to be able to drop the component on two different
forms and then have the forms 'communicate' via a shared event mechanism.
Again, the lazy part of me is trying to avoid having to add code to my forms
that's not already in the InitializeCompo nent method created by Visual
Studio. So to use the Singleton Design Pattern, I would have to go into all
of my forms and do something to set the form's instance of the object back
to the Singleton object, and then re-connect the event handlers. I know it's
only a couple lines of extra code, but I've got several forms to keep
synched up and sticking to my hopeful plan would make it a bit easier.

Thanks,
Chris

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

I think that what you want is the Singleton pattern. Grab a copy of the
Gang of Four (Design Patterns by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides), or surf to Jon Skeet's page on Singleton
in C#:

http://www.yoda.arachsys.com/csharp/singleton.html

Essentially, what you want is to make MySpecialObject a singleton, so
that you say:

MySpecialObject A = MySpecialObject .Instance;
A.FireSpecialEv ent();

and elsewhere

MySpecialObject B = MySpecialObject .Instance;
B.FireSpecialEv ent();

and both A and B are the same object instance.

[Brendan Grant]

Interesting case... One other option... which would depend on how the objects
are initialized... would be some remoting...

If you were to use RegisterWellKno wnServiceType() to register your class as
a Singleton WellKnownObject Mode... you could then register the class again
within the AppDomain with RegisterWellKno wnClientType().

Under this method... any following new instances of the registered class
will actually be remoted to a central, single instance of the class... this
would work... however I would highly advise against it.

Brendan
"Christophe r D. Wiederspan" wrote:

Actually, I've already looked at this design pattern, and it would be what I
need except for this: I'm being lazy and MySpecialObject is actually a class
that inherits from Component, so it shows up in my Toolbox when designing
Windows Forms. My goal was to be able to drop the component on two different
forms and then have the forms 'communicate' via a shared event mechanism.
Again, the lazy part of me is trying to avoid having to add code to my forms
that's not already in the InitializeCompo nent method created by Visual
Studio. So to use the Singleton Design Pattern, I would have to go into all
of my forms and do something to set the form's instance of the object back
to the Singleton object, and then re-connect the event handlers. I know it's
only a couple lines of extra code, but I've got several forms to keep
synched up and sticking to my hopeful plan would make it a bit easier.

Thanks,
Chris

"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

I think that what you want is the Singleton pattern. Grab a copy of the
Gang of Four (Design Patterns by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides), or surf to Jon Skeet's page on Singleton
in C#:

http://www.yoda.arachsys.com/csharp/singleton.html

Essentially, what you want is to make MySpecialObject a singleton, so
that you say:

MySpecialObject A = MySpecialObject .Instance;
A.FireSpecialEv ent();

and elsewhere

MySpecialObject B = MySpecialObject .Instance;
B.FireSpecialEv ent();

and both A and B are the same object instance.

[Bruce Wood]

Armed with this additional information, what I would suggest is that
you want to decouple your presentation from your model. I claim that,
in fact, you don't want your two components communicating with each
other. What you want is that each component is simply a visual
representation of the same model object, which contains the data being
displayed. Whenever the data changes, your model raises an event to
which your components listen and change the visual representation.
Whenever the user manipulates a control, the component changes the
model, which raises an event, which changes the visual representations
of the two components.

In other words, you need another class to act as a central holding bin
for your components' data, and have your controls interact with each
other through the model. You can use the IDE to connect the components
to the model's events if you make the model itself a Component.

The fancier version of this is called Model-View-Presenter.

Trust me, as complicated as it sounds, it's a lot simpler than trying
to make the two "views" talk to each other directly. I already went
down that route and found that the complexity soon spiraled out of
control.