Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 Nov 26 '12 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 Nov 26 '12 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 Nov 26 '12 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 Nov 28 '12 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 Dec 10 '12 at 18:17

1 Answer 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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