In my project, I have a collection of classes. These classes for the most part contain data which is updated infrequently or not at all – that is they don’t really do much – their purpose is to be passed around consumer objects that do do things, seperating data from functionality.

I would like to continue this model, by allowing the user to treat them as such – i.e. they can be serialised/deserialised with no special code, can easily be used to compose larger classes, subclassed, etc.

The catch is, as many control things like the GPU, they aren’t really decoupled or stateless at all, because for every one there are a whole load of resources that need to be created and disposed of during the life of the application – but the user doesn’t need to worry about that.

I would like to know the preferred way to attach all the information to the simple object in a way that is safe, maintains the illusion of statelessness, but is also clear to anyone else looking at the code what is going on (also, the objects are defined in different assemblies).

Q. Why not just put A in B and pass around Object B?
A. Because the user creates Object A, and works with Object A only, and shouldn’t need to know Object B exists at all.

Q. Why not use factories and create Object C?
A. Because then Assembly A can’t contain classes composed of a whole load of Object-A-like-objects (because the factory would be defined in Assembly B so they wouldn’t be able to be instantiated).

Q. Then how is Object B created?
A. Object B is created and populated on demand, when Object A is passed to a method that needs it.

Note – I know this problem isn’t ‘hard’ and there are many ways to do it (at the moment I have an abstract member added to all of them which is casted in the consumer and it works OK), I just want some new ideas/opinions on what is the best way – what would you like to see if you inherited the code?