title: Architecture: Modifying the model in different ways
body: <h2>Problem statement</h2>
  
  <p>I have a model class that looks something like (<em>extremely</em> simplified; some members and many, many methods omitted for clarity):</p>
  
  <pre><code>class MyModelItem
  {
  public:
      enum ItemState
      {
          State1,
          State2
      };
  
      QString text() const;
  
      ItemState state() const;
  
  private:
      QString _text;
  
      ItemState _state;
  }
  </code></pre>
  
  <p>It is a core element of the application and is used in many different parts of the code:</p>
  
  <ul>
  <li>It is serialized/deserialized into/from various file formats</li>
  <li>It can be written into or read from a database</li>
  <li>It can be updated by an 'import', that reads a file and applies changes to the currently loaded in-memory model</li>
  <li>It can be updated by the user through various GUI functions</li>
  </ul>
  
  <p>The problem is, this class is has grown over the years and now has several thousands lines of code; it has become a prime example of how to violate the <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle">Single responsibility principle</a>.</p>
  
  <p>It has methods for setting the 'text', 'state', etc. directly (after deserialization) and the same set of methods for setting them from within the UI, which has side effects like updating the 'lastChangedDate' and 'lastChangedUser' etc. Some methods or groups of methods exist even more than twice, with everyone of them doing basically the same thing but slightly different.</p>
  
  <p>When developing new parts of the application, you are very likely using the wrong of the five different ways of manipulating <code>MyModelItem</code>, which makes it extremely time consuming and frustrating.</p>
  
  <h2>Requirements</h2>
  
  <p>Given this historically grown and overly complex class, the goal is to separate all different concerns of it into different classes, leaving only the core data members in it.</p>
  
  <p>Ideally, I would prefer a solution where a <code>MyModelItem</code> object has nothing but <code>const</code> members for accessing the data and modifications can only be made using special classes.</p>
  
  <p>Every one of these special classes could then contain an actual concrete implementation of the business logic (a setter of 'text' could do something like <em>"if the text to be set begins with a certain substring and the state equals 'State1', set it to 'State2'"</em>).</p>
  
  <h2>First part of the solution</h2>
  
  <p>For loading and storing the whole model, which consists of many <code>MyModelItem</code> objects and some more, the <a href="http://en.wikipedia.org/wiki/Visitor_pattern">Visitor pattern</a> looks like a promising solution. I could implement several visitor classes for different file formats or database schemas and have a <code>save</code> and <code>load</code> method in <code>MyModelItem</code>, which accept such a visitor object each.</p>
  
  <h2>Open question</h2>
  
  <p>When the user enters a specific text, I want to validate that input. The same validation must be made if the input comes from another part of the application, which means I can not move the validation into the UI (in any case, UI-only-validation is often a bad idea). But if the validation happens in the <code>MyModelItem</code> itself, I have two problems again:</p>
  
  <ul>
  <li>The separation of concerns, which was the goal to begin with is negated. All the business logic code is still 'dumped' into the poor model.</li>
  <li>When called by other parts of the application, this validation has to look differently. Implementing different validating-setter-methods is how it is done right now, which has a bad code smell.</li>
  </ul>
  
  <p>It is clear now that the validation has to be moved outside both the UI and the model, into some sort of controller (in a MVC sense) class or collection of classes. These should then decorate/visit/etc the actual dumb model class with its data.</p>
  
  <p><strong>Which software design pattern fits best to the described case, to allow for different ways of modifying the instances of my class?</strong></p>
  
  <p>I am asking, because none of the patterns I know solves my problem entirely and I feel like I'm missing something here...</p>
  
  <p>Thanks a lot for your ideas!</p>