Bad idea to have the same object, have a different side effect after method call.

Answer 1

I would allow the ButtonPad to create its own ComInstance. I note in your sequence diagram, that the ButtonPad is the only object that touches the ComInstance. So keep it internal.

Answer 2

I would agree with John's answer.

The other alternative would be to replicate the internal state of the ButtonPad to the COM Object when you instantiate it.

ie: Option 1 (John's) is to create the COM Object from the ButtonPad constructor.

Option 2 is to reflect the state of ButtonPad to the COM Object inside ButtonPad.CreatePad(...). ButtonPad.CreatePad(...) would then call CreateButtonPad on the COM object, and then call SetTitle(), etc. on the COM Object before returning so that ButtonPad ensures that the state of the COM Object is consistent.

I would prefer option 2 if it makes sense for the ButtonPad to exist without the COM Object, or possibly if you didn't have access to the IComObject required to instantiate the COM Object at the time the ButtonPad is instantiated. Otherwise I'd go with option 1.

Answer 3

I'd first ask: what's the use case for manipulating ButtonPad properties independently of the underlying properties that they're hiding? There are most likely two answers for that: 1) there isn't one, 2) it's critically important that we be able to do that.

The answer in the first case is pretty straightforward: create the underlying COM object in your class's constructor, map your properties onto its properties, and call it a day.

In the second case, though, you're getting into territory that smells a lot like data binding. You have a data source (your object), the thing it's bound to (the COM object), the need to convert property values between the two things (i.e. parsing and formatting, if the communication is two-way), and possibly even a need for mapping property changes through event notifications. (Like, if something else manipulates a property of the COM object, does your .NET object need to be notified?)

I'm not saying that you'd actually want to use binding to do this, but I'd certainly look at the way .NET data binding is designed and see how many pieces of that design you actually are going to need.

In all likelihood, you'll look at it and say "Wow, that's really complicated." That's because what you're trying to do is fundamentally really complicated. It's a lot more complicated if your design doesn't implement separation of concerns.