1

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).

enter image description here

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?

6
  • 3
    I find it relatively hard to believe that the dictionary lookup is too slow. If that much of your processing is working with metadata rather than the object itself, I question which is the metadata and which is the data. Some more detail might help answer the question better.
    – Telastyn
    Commented Nov 26, 2012 at 19:52
  • @Telastyn, I have added more detail, and rephrased that section to express my concerns more accurately - its not so much that the dictionary is 'slow', its that is slow in comparison to a 'direct reference' in a section of code which is very time sensitive.
    – sebf
    Commented Nov 26, 2012 at 20:02
  • (I should say, if this sounds like premature optimisation, there was another section of my code that did originally use lookups, but they were re-factored out when it became the source of performance problems, so I do have some reason for it ;))
    – sebf
    Commented Nov 26, 2012 at 20:05
  • @sebf That's exactly why it's called “premature optimization”. Just because it made sense in another part of your code, doesn't mean it makes sense here too. Measure your code and search for faster solution only if what you have now is actually too slow. And don't forget to consider the fact that it might not have been a problem with the dictionary per se, but with your implementation of GetHashCode().
    – svick
    Commented Nov 28, 2012 at 17:35
  • What "hardware resources" does the consumer need to create and why does it need to associate them with a NeatObject?
    – Ed Hastings
    Commented Dec 10, 2012 at 18:17

1 Answer 1

Reset to default
1

Simple Composition.

Have NeatObject and HardwareResources be composed within a BuiltNeatObject or something. One part comes from serialized resources, the other is spawned at runtime by the consumer and they live together (ideally in a read-only/immutable state), even if they're consumed independently.

A Factory might be useful to hide 'how' the two parts are aggregated, but then again it might limit flexibility in the future. I'll leave that to you since you know the problem best.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.