I am considering the use of valueTrees for a half-finished project I’m currently working on, but cannot yet decide it if it a good idea for my needs, so I thought I’d start a philosophical discussion about it to help make my mind up.
First and foremost: do any of you know of any design pattern(s) that would be the equivalent of Juce’s ValueTree implementation, alone or in combination?
That’d help me read up on it outside this forum!
Second: It seems that With valueTree, traditional GOF OO approaches are turned inside out!
Let me explain: at the moment my program is based around the traditional Gang of Four patterns of Composite for the model, with Visitors for serialization and other traversing of the model, and the Command pattern around which an undo-redo implementation is straightforward, if a bit verbose. Each element in my model is then sub-classing from the Composite pattern classes, and can additionally encapsulate all its logic, with similar classes easily sharing interfaces and behavior, as per usual.
With ValueTree though, the above (if it is clear at all the way I’ve described it), is in effect turned inside out: the complexity of the tree is at all times exposed in the program, and instead of a class encapsulating all its complexity, the complex model has to have any logic and related extra data-structures hanging off it! The discussion in this thread seems to be similar: http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=6744&p=37673&hilit=valuetree#p37673
In a program that potentially updates hundreds of values a second, and at times uses hash-tables to store and retrieve values speedily, perhaps the above doesn’t gel well?
At the moment I am still just thinking of the pros and cons, hence the rambling nature of the second part of this post…
Hopefully I will reach some clarity in which case I will post back to this thread and share my profound OO design insights