 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2007Immutable object graph
I have a graph of Leafs and Nodes. A Node has 0...n Leafs A Leaf has 1...2 Nodes. The referencing is circular. During execution I wish to modify both Nodes (eg add/remove Leafs) and Leafs (eg add a Node to a single Noded Leaf). The Leaf is easy to make Immutable, but does it make sense to make the Node immutable? Since my model holds a collection of references to all the nodes[1], the collection itself, is mutable so I can swap nodes in and out if I were to have an immutable Node. The overhead of recreating Nodes and linking them is not going to be a problem. Really my concern is the simplicty of the code. On one hand immutables themselves are simple and have the usual advantages but on the downside there will be more code that has to reestablish the natural composition references that would otherwise (with a mutable) already exist. If I end up having a mixture of Mutable Node and Immutable Leaf, then I'll have Sets of Leafs and Lists of Nodes, since I see it non-sensical (and error prone) to have a Set of mutables. But I guess that doesn't matter. [1] I don't rely on traverseing the graph because there are non-contiguous graph portions. TIA,  SignatureMike W ... > If I end up having a mixture of Mutable Node and Immutable Leaf, then I'll > have Sets of Leafs and Lists of Nodes, since I see it non-sensical (and > error prone) to have a Set of mutables. But I guess that doesn't matter. ... I don't see the reason for avoiding a Set of mutables, provided those things that affect the Set contract and implementation are immutable. In particular, I see no problem with a HashSet<Node> if Node directly extends Object and overrides neither equals nor hashCode. Patricia > ... >> If I end up having a mixture of Mutable Node and Immutable Leaf, then [quoted text clipped - 10 lines] > > Patricia Thanks Patricia, I'll see how I get on. -- Mike W >I have a graph of Leafs and Nodes. > A Node has 0...n Leafs [quoted text clipped - 5 lines] > The Leaf is easy to make Immutable, but does it make sense to make the > Node immutable? It seems to me that I wish to modify both Nodes and Leafs and The Leaf is easy to make Immutable contradict each other. >>I have a graph of Leafs and Nodes. >> A Node has 0...n Leafs [quoted text clipped - 12 lines] > > contradict each other. When I wrote that I thought, 'shall I be totally precise or will it get the point accross?' ...Alas. So by modify an immutable I mean obtain an instance that reflects the new state I require. I mean it really goes without saying, you can't Modify an Immutable, doesn't it? Leaf newLeaf = oldLeaf.withNewFoo(myFoo); SignatureMike W > >>I have a graph of Leafs and Nodes. > >> A Node has 0...n Leafs [quoted text clipped - 25 lines] > -- > Mike W So, your object graph itself is not immutable, but the nodes within it may be? That doesn't quite make sense either. In any case, isn't a Leaf just a type of Node? Often they are implemented using the same class, as their behavior is the same. Another common approach is a Node class and an Edge class. >> So by modify an immutable I mean obtain an instance that reflects the new >> state I require. [quoted text clipped - 9 lines] > So, your object graph itself is not immutable, but the nodes within it > may be? That doesn't quite make sense either. Item13: Always favour Immutability > In any case, isn't a Leaf just a type of Node? Often they are > implemented using the same class, as their behavior is the same. > Another common approach is a Node class and an Edge class. Yes I really mean Edge not Leaf (sorry for confusion) SignatureMike W > Item13: Always favour Immutability "Always favor" != "Always use" You are supposed to think about the situation. Dogma is unreliable. SignatureLew >> Item13: Always favour Immutability > > "Always favor" != "Always use" > > You are supposed to think about the situation. Dogma is unreliable. You snipped the context, it was a response to the confusion of another poster. I don't think I've said 'always use'. SignatureMike W >>> Item13: Always favour Immutability >> "Always favor" != "Always use" [quoted text clipped - 4 lines] > poster. > I don't think I've said 'always use'. I wasn't trying to take issue with what you said but to point out for other readers what the limitations are of such principles. SignatureLew >>>I have a graph of Leafs and Nodes. >>> A Node has 0...n Leafs [quoted text clipped - 20 lines] > I mean it really goes without saying, you can't Modify an Immutable, > doesn't it? This time, at least, it helped to say it. But (and I'm not trying to be difficult, honestly) if you're going to "modify" a leaf by making a new instance of it, the things that point to leaves (i.e. Nodes) need to be mutable. Otherwise, when you change any Leaf, you'll have to recreate the Nodes that point to it, and the leaves that point to *them*, and the Nodes that point to *them*, ... in other words the entire graph. > But (and I'm not trying to be difficult, honestly) if you're going to > "modify" a leaf by making a new instance of it, the things that point to > leaves (i.e. Nodes) need to be mutable. Otherwise, when you change any > Leaf, you'll have to recreate the Nodes that point to it, and the leaves > that point to *them*, and the Nodes that point to *them*, ... in other > words the entire graph. Yes but most of the objects will be reused. Changing a Leaf will only cause instantiation of that Leaf and its Nodes. Anyway expense isn't an issue, code elegance and simplicity is the aim. With that in mind, however, I think perhaps the best solution is Mutable Nodes and Immutable Leafs. SignatureMike W > I have a graph of Leafs and Nodes. > A Node has 0...n Leafs [quoted text clipped - 23 lines] > -- > Mike W So it if I have it right, you'd prefer to have everything immutable, whilst also be able to insert and remove nodes within the tree... If thats right, then this is possible, and used by the AWTSwing event system, to provide thread safe yet non-blocking structures of Publish- subscribers. Take a look at (old but good) http://www.javaworld.com/javaworld/jw-03-1999/jw-03-toolbox.html for an example about how you could achieve this. Andrew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.