Bad idea to have the same object, have a different side effect after method call.
- by Nathan W
Hi all,
I'm having a bit of a gesign issue(again). Say I have this Buttonpad object:
now this object is a wrapper object over one in a com object. At the moment it has a method on it called CreateInto(IComObject). Now to make a new button pad in the Com Object.
You do:
ButtonPad pad = new ButtonPad();
pad.Title = "Hello";
// Set some more properties.
pad.CreateInto(Cominstance);
The createinfo method will excute the right commands to buid the button pad in the com object. After it has been created it any calls against it are foward to the underlying object for change so:
pad.Title = "New title";
will call the com object to set the title and also set the internal title variable.
Basically any calls before the CreateInfo method only affect the .NET object anything after has the side effect of calling the com object also. I'm not very good at sequence diagrams but here is my attempt to explain whats going on:
This doesn't feel good to me, it feels like I'm lying to the user about what the button pad does.
I was going to have a object called WrappedButtonPad, which is returned from CreateInto and the user could make calls against that to make changes to the Com Object, but I feel having two objects that almost do the same thing but only differ by names might be even worse.
Are these valid designs, or am I right to be worried?
How else would you handle a object the can create and query a com object?