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.

I have a number of objects storing state. There are essentially two types of fields. The ones that uniquely define what the object is (what node, what edge etc), and the others that store state describing how these things are connected (this node is connected to these edges, this edge is part of these paths) etc. My model is updating the state variables using package methods, so all these objects act as immutable to anyone not in Model scope. All Objects extend one base type.

I've toyed with the idea of a Factory approach which accepts a Builder object and constructs the applicable object. However, if an instance of the object already exists (ie would return true if I created the object defined by the builder and passed it to the equal method for the existing instance) the factory returns the current object instead of creating a new instance. Because the Equal method would only compare what uniquely defines the type of object (this is node A to node B) but won't check the dynamic state stuff (node A is currently connected to nodes C and E) this would be a way of ensuring anyone that wants my Node A automatically knows its state connections. More importantly it would prevent aliasing nightmares of someone trying to pass an instance of node A with different state then the node A in my model has.

I've never heard of this pattern before, and it's a bit odd. I would have to do some overriding of serialization methods to make it work (ensure that when I read in a serilized object I add it to my facotry list of known instances, and/or return an existing factory in its place), as well as using a weakHashMap as if it was a weakHashSet to know whether an instance exists without worrying about a quasi-memory leak occuring. I don't know if this is too confusing or prone to its own obscure bugs.

One thing I know is that plugins interface with lowest level hardware. The plugins have to be able to return state that is different than my memory; to tell my memory when its own state is inconsistent. I believe this is possible despite their fetching objects that exist in my memory; we allow building of objects without checking their consistency with the model until the addToModel is called anyways; and the existing plugins design was written before all this extra state existed and worked fine without ever being aware of it.

Should I just be using some other design to avoid this crazyness? (I have another question to that affect that I'm posting).

share|improve this question
5  
It sounds like you are designing a variant of the Singleton design pattern (one instance for each concrete set of constant properties), although your design also has some similarities with the Flyweight pattern. –  Bart van Ingen Schenau Apr 29 '13 at 15:17
    
Yes it is a version of singleton; but everyone hears singleton and immediately says your clearly wrong because singleton is an anti-pattern. Figured I would explain what was really happening before someone told me I was doing an anti-patern lol –  dsollen Apr 29 '13 at 20:08
1  
singleton with a lower-case is just great (you make sure there is only one instance), it's Singleton with an upper case (where everyone everywhere in the application has a reference to it), which is the problem. –  Amy Blankenship Apr 30 '13 at 2:34
1  
The pattern you're describing is exactly how the Actionscript framework Robotlegs works (you can map a factory to return a new instance or map it to only to return a new instance if one doesn't exist). I don't know for sure that frameworks in other languages work exactly this way, but I'd suspect many do--the contributors are quite well-read about design patterns in general, and Actionscript's not their only language. –  Amy Blankenship Apr 30 '13 at 2:37
    
The question is written in a overly complex style. –  user61852 Jun 29 '13 at 3:13
add comment

1 Answer

up vote 1 down vote accepted

The pattern you are conceptualizing is called memoization, and is much more common in functional programming but is also used heavily in games programming.

As long as you encapsulate your implementation, and don't have special cases that will drive other programmers crazy, you should be in the clear.

http://en.wikipedia.org/wiki/Memoization

share|improve this answer
    
Perhaps I'm confused, but I looked into the memento pattern and it doesn't seem to be the same thing? Memento is designed to allow rolling back of state when something fails. I already have a way to rollback state using exception handling (though I will look into rather memnto would be a better option). What I'm looking for is not an ability to rollback state; but an ability to ensure everyone always has the same state for a given object type. –  dsollen Apr 29 '13 at 20:16
    
Ah, my bad! I'm thinking of memoizing, which for some reason my brain transliterated as momento. –  Jonathan Rich Apr 29 '13 at 20:19
    
Thank you, I have looked up the pattern. It really sounds as if it's considered mostly functional and mostly for spead optimization. Using it as protection against aliasing would not be considered a 'code smell'? THat's my main concern, that even if I implemented it I may be making the conceptual program more complex rathern then resolving some simpler issue. Also if you don't think this is a problem then do you know of any java packages that do it automatically (I've found none with my search, as I said it doesn't look like it's done by java programers). –  dsollen Apr 29 '13 at 22:15
    
Here's a relevant SO question: stackoverflow.com/questions/3934777/java-automatic-memoization –  Jonathan Rich Apr 30 '13 at 12:42
add comment

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.