Design Patterns – Design Pattern for Configuring Objects

datadesigndesign-patterns

Context

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.

Problem

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.

Question

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.

Best Answer

Funnily, while writing the question part of the post, I wrote this:

I can't create subclass for each data entity (object, action, ... etc), but I can create a generic subclass that fits all the objects.

That's it!

Even though the prefab factory can configure the instantiated object on-the-fly, it can only do that when the object is created for the very first time. When it is loaded from the model, it is more or less de-serialized, which meant I had to traverse the model tree... Which was so ugly, I couldn't write such code. Writing a custom subclass to rule them all, I can have it configure itself even when loaded from a serialized data model.

(Final remarks: I didn't want all that typing in the question to go to waste, besides stackexchange promotes Q&A style spreading knowledge kinda thing, so, yay)

Related Solutions

Design Patterns – Best Design Pattern for Library with Data Model

I could be waaaaaay off, but...

It seems that a model is necessary to use the library, you just don't care which one, right? Further, the library doesn't care how the model gets its data, or where the data comes from, it just wants an object that meets the criteria of the interface.

If the library doesn't need the connection object, then make that the responsibility of the model.

interface MyFooModelInterface 
{
    public function getItem($id);
    public function addItem($item);
    ...
}

And here is a simple class example:

class MyLib
{
    protected $model;

    public function __construct(MyFooModelInterface $model)
    {
        $this->model = $model;
    }

    public function getItemById($id)
    {
        return $this->model->getItem($id);
    }
}

And a Model example:

class MyModel implements MyFooModelInterface
{
    protected $conn;

    public function __construct(\PDO $conn)
    {
         $this->conn = $conn;
    }

    public function getItem($id)
    {
        ...
    }
    public function addItem($item)
    {
        ...
    }
}

And here is an example of using it:

// the model is responsible for handling the data retrieval, not the library
$model = new Model($conn);

$lib = new MyLib($model);
return $lib->getItem($id);

Now, if I decide that I want a file-based solution, I can easily swap the model. To test the model, the connection obj is injected, so that's easy. To test the library, the model is also injected, so, again, that's easy.

In this case, the model is only responsible for getting the data, while the library is responsible for handling and processing the data. Neither cares what or how the other one does it.

EDIT

the library with a factory method to create the model if none was given...

class MyLib
{
    protected $model;

    public function __construct(MyFooModelInterface $model = null, $conn = null)
    {
        // if we have a model, use it
        if (!is_null($model)) { 
            $this->model = $model; 
        }

        // if we don't have a model, but have a connection obj, make a model
        if (is_null($model) && !is_null($conn)) { 
            $this->model = $this->factoryModel($conn); 
        }

        // if we don't have either, quit and go home
        if (is_null($model) && is_null($conn)) {
            throw new Exception('need moar inputs');
        }
    }

    protected factoryModel($conn)
    {
        $this->model = new MyModel($conn);
    }

    public function getItemById($id)
    {
        return $this->model->getItem($id);
    }
}

Building presentation layer directly on data layer

If you skip your business or domain layer the issue is that you will need to put your business logic somewhere, and it will likely end up in both your ui and data layer, which will make your application increasingly difficult to maintain. The other issue is that your ui and data layer will likely need to be replaced, such a when you want to move to wpf from winforms, or SQL to EF. So even though it might take a bit longer, create your business later up front, with proper unit tests.