Reputation: 2121
I'm working on a tree-structured storage and we currently use transaction methods to modify the tree-structure. I always thought using the Command Pattern would be appropriate. However I just changed a small behaviour and I like it (returning the transaction instance located at the inserted node (except for attributes)):
wtx.insertText(EInsert.ASRIGHTSIBLING, "value").insertElement(EInsert.ASRIGHTSIBLING, new QName("bla").insertElement(EInsert.ASFIRSTCHILD, new QName("blubb")).insertAttribute(new QName("foo"), "bar").insertAttribute(new QName("bar"), "foo"));
I think chaining the operations this way is very nice, but our transactions provide cursor like methods on the tree (moveTo(long)
, moveToParent()
, moveToFirstChild()
...) which return boolean values instead of the current transaction instance, but I think this can't be avoided. Otherwise we could even do moves between without the cumbersome
wtx.method();wtx.method();wtx.method();
However I thought about the command pattern which would be
new InsertText(EInsert.ASRIGHTSIBLING, "value").execute(wtx);
new InsertElement(EInsert.ASRIGHTSIBLING, new QName("bla")).execute(wtx);
...
which is a bit more verbose but well, it would "support" the open/closed principle which is really nice.
So, what do you think?
Upvotes: 0
Views: 509
Reputation: 1023
The tree structure to me sounds like it can be described like a giant composite object. Since you're also dealing with building a transaction I think using the Command pattern would be appropriate but you should consider wrapping your execute() calls in some kind of director if possible such that you kind of mash the Command and Builder patterns together if possible.
public void directorMethod(Object wtx) {
InsertText(EInsert.ASRIGHTSIBLING, "value").execute(wtx);
InsertText(EInsert.ASRIGHTSIBLING, "blah").execute(wtx);
}
Note, the void return could be your tree structure and the wtx parameter can be the transaction and/or tree structure, I'm not necessarily sure how you would want to do it. The idea of using the Builder would be to abstract the building of the Composite transaction from the underlying implementation. That way if you need to change an underlying command, you should be able to do so and test atomically.
Upvotes: 1