I am caught between two conceptual models of how to construct objects, and am having trouble working out what standard I want to adopt.
I prefer to program in .NET and often try to use RAII and read-only properties to make immutable objects with their data passed in through constructor parameters. This has been a major advance compared to the VB6 days when we had to simulate constructors and by convention call "Init" or "Factory.Create" to get objects into a good state.
However, I am often making COM-callable wrappers to let me call functions via Automation from other applications. As you probably know, COM wants objects to have a constructor without any parameters. This is a dissonance with the RAII/immutable scheme that I have been using with such success in the .NET world.
I remember older object models like ADO where you would usually instantiate an object, set properties like ConnectionString, then call Open. The object could be immutable not via a ReadOnly declaration, but via throwing an "Can't change while open" exception on the property setter.
Is this the best pattern to use for COM? Am I missing a better way to skin this cat? Since RAII came out of the C++ community, how do they handle COM being based on a different initialization scheme?