在MVC 模型中，M 代表模型。M中的信息可以访问到模型的信息。
我们在很多代码中看到，有些模型也负责draw 自身的逻辑。一个模型知道如何画自身似乎是很合理的。
如果细想一下，draw 跟模型中的其他功能相比，似乎是一个别的职责。模型是否应该拥有此职责!
呢？
放在模型中的影响：
因为draw是依赖于设备和底层图形的接口的。如果draw在模型中，那么模型的这个层(layer)，就需要依赖一个显示绘画层。
这显然是不好的设计：
- 我们希望模型层只是模型，数据. 做unit test时候，基本不需要对模型层进行cover, 因为里面只有数据。
但是现在因为有了画的逻辑存在， model层就需要unit test 覆盖。 - 当application层需要做unit test时候，需要new model,此时也是非常麻烦的，我们还要构造显示层。
更大的弊端
在业务中，draw除了对显示层有依赖，也可能对其他的Model有依赖。比如金箍棒model和孙悟空Model。 对于金箍棒，它在draw的时候， 还需要知道孙悟空手的位置已经方向。
对于这种情形，可能的一个解决办法是，让金箍棒模型对孙悟空模型产生依赖。这种弊端非常明显，使得模型层依赖混乱。理想的模型层里面的模型，应该是相互独立的，没有相互依赖。
separate responsibility
iteration1:
将draw的职责从模型中分离出来。模型之间相互没影响。
好处：
- 模型对显示层没有了依赖，模型只负责模型，没有其他职责
- 模型的draw 功能分离了
**iteration 2: **
刚才我们还提到，在draw的时候，一个模型可能对别的模型有依赖，因此我们可以做一个非常thin layer ,单独为了draw. 这个layer比模型稍微高些。
