What is the preferred pattern when attaching a 'runtime object'?
Posted
by
sebf
on Programmers
See other posts from Programmers
or by sebf
Published on 2012-11-26T19:46:08Z
Indexed on
2012/11/26
23:23 UTC
Read the original article
Hit count: 153
c#
|design-patterns
In my application I have the following:
public class NeatObject
{
/* lots of static data, and configuration flags */
}
public class NeatObjectConsumer
{
void DoCleverStuffWithObjectOnGPU(NeatObject obj);
}
Where NeatObject and its consumer are used to control the GPU.
The idea being that, the configuration of an instance of NeatObject and its members, define how the consumer instance behaves. The object can be passed around, edited, and most importantly serialised/deserialised by the application, with and without knowledge of NeatObjectConsumer, then provided back to the consumer to do something else.
The purpose of this seperation is:
- The consumer manages hardware resources, which change depending on the computer, and even on the execution of the application, making preserving the state of an object which does everything difficult.
- Avoids circular references if the assembly that contains the consumer needs to reference one that only needs to know about NeatObject.
However, there is a complication in that the consumer creates hardware resources and needs to associate them with NeatObject. These don't need to be preserved, but still need to be retrieved. DoCleverStuffWithObjectOnGPU() will be called many, many times during execution and so any bottleneck is a concern, therefore I would like to avoid dictionary lookups.
What is the preferred method of attaching this information to NeatObject?
By preferred, I mean intuitive - other coders can see immediately what is going on - and robust - method doesn't invite playing with the resources or present them in such a way as to make them easily corruptible.
Essentially, I want to add my own metadata - how should I do it? Try to use 'actual metadata' functionality like Reflection? A member of the type of an abstract class? Unmanaged pointers?
If you took on a project that used this pattern, what would you have liked the previous developer to do?
© Programmers or respective owner