In a Cocoa application I am developing, I need to load a data model that is defined in plist files. So, I have something like:
root (Array) ---- item (Dictionary) -------- name : "objects" (string) -------- prefab : "object" (string) -------- children : (Array) ... ---- item (Dictionary) -------- name : "actions" (string) -------- prefab : "action" (string) -------- children : (Array)
So, the previous data model is loaded in the code to become an object representation using the language's primitives (arrays, dictionaries, strings, ... etc). No custom classes here. When I load that model, I know that an item in the table view can have children if the "prefab" key is set. When "add child" is pressed, I go to the prefabs (some other plist) and fetch that prefab's structure. e.g:
root (Array) ---- item (Dictionary) -------- name : "object" (string) -------- parameters : (dictionary) ------------ key "object_id" : value "" ------------ key "x_position" : value 0 ...
As you can see, from the prefab in the first model, I can go to the second plist and fetch a structure that is defined in a plist. All loaded using a plist library, without any subclass creation whatsoever. There is a single prefab factory class that contains the prefab structures, and instantiates and initializes the object from the prefab with the configuration data.
I hope you see the grave danger in this design. The model contains both user generated data as well as configuration data!! EEEEK!!! ... Sheesh, that's so bad...
The problem haunted me when I started exporting the model after the user of the app interacted with the model though the UI. The exported model would contain the configuration data (such as the prefab key), which makes the exported data rigid and un-upgradable. If I were to change the prefab key in later version of the app, to something else, and you load an old model, that model will load the old configurations with it, in our case, referencing the old prefab.
I need help find a proper design pattern that clicks with this data driven design that I have, by providing the configuration data from a separate file, and somehow, linking it with the data model.