为什么学习设计模式
在明白为什么学习设计模式之前，这学期我第一次在学校上了软件工程这门课。
课上老师有一个思想和说法，令我耳目一新，改变了我原有对于软件开发的认识，大概意思是:
与建筑工程这类看的见的实体工程一样，我们的软件开发也是一项真正的工程。
我们需要结构的设计，来保证安全，美观，好用。也需要合理的分工，来达到最好的结果。
从此，我对待软件开发的学习态度也大不一样，我知道自己开发的不是什么随随便便的小东西——而是运用真正的科学技术，去开发的软件工程。
因此不应该盲目地copy，随便用廉价的代码去拼凑。那样出来的，只是豆腐渣工程。
我苦于自己代码糟糕的结构，以及臃肿的controller。
直到阅读到前辈们的博客，给了我指引。其中一个关键就是设计模式的运用。
设计模式是有用的抽象化工具，相当于一个对象或类的设计模板，用来解决特定领域经常发生的问题。
MVC
MVC 模式，顾名思义，它是这样一种模式:
模型 Model- 视图 View - 控制器Controller
听起来很简单。
其实到今天，我才开始真正理解它。它本身其实并不是最基本的设计模式。
它至少在 Samlltalk 诞生初期就已经出现。在 MVC 设计模式中，对象被分为模型，视图，控制器。它是Cocoa Touch中很多机制和技术的基础。
在模型对象中，封装数据和基本行为
模型对象，用于维护应用程序的数据，并定义操作数据的特定逻辑。
只要加载的是包含有应用程序永久信息的数据，就应该将其放入模型对象。
如果是理想状态，模型对象与对其进行显示和编辑的用户界面，不应有任何的直接关联。
使用视图对象，向用户展示信息
视图对象，可以响应用户的操作，并懂得如何将自己展现在屏幕上。
视图对象通常从应用程序的模型对象获取数据，用于展示。
值得注意的是，虽然视图对象与模型对象关系密切，但是在MVC应用程序中，它们之间没有耦合。
用控制器对象，联系起模型和视图
控制器对象，就是是视图对象和模型对象的中间人。
控制器对象就像一个厨师，模型对象是材料，视图对象是服务员，厨师烹饪对应的材料，然后交由我们的视图对象进行呈现。
除了协调作用之外，控制器还可以执行其他的操作。
作为复合模式的MVC
MVC模式包含了若干更加基本的设计模式。在 Cocoa(Touch) 的 MVC 有:
组合（Composite）
视图对象之间，以协作方式，构成一个视图层次结构体系。
其中既可以有复合视图，也可以有独立视图。
每个层次的每个视图节点，都可以响应用户的操作，并把自己绘制到屏幕上。
命令(Command）
这是一种“目标-动作”机制，视图对象可以推迟其他对象的执行。
让其他对象等到发生了某些事件后，再执行。
中介者(Mdediator)
控制器对象，采用了中介模式。构成了模型对象和视图对象之间传递数据的双向通道。
应用程序的控制器对象，将模型的变更，传达给视图对象。
策略(Strategy)
控制器对象，可以是视图对象的一个“策略”。
视图对象，将自身隔离，以期维持其作为数据展示器的唯一职责。而将一切应用程序特有的界面行为的决定，委派给它的“策略”对象。
观察者(Observer)
模型对象向它所关注的控制器对象，发出内部状态变化的通知。
针对接口编程，而不是针对实现编程
作为一个软件开发人员，很多人甚至已经学习了多门面向对象的语言。对于类，对象，继承，多态，接口的概念相信都已经理解了。
但是类继承与接口继承的区别在哪里？
接口定义了类型，接口继承让我们可以用一个对象，代替另一个对象。
类继承，是通过复用父类的功能或者只是简单的共享代码和表述，来定义对象的实现和类型的一种机制。
@protocal 与抽象基类
我们要针对接口编程，而 OC 中，有一种称为协议的语言功能(语法为@protocal)。
协议不定义任何实现，而只声明方法，以确定符合协议的类的行为。
因此，协议是只定义抽象行为的”接口”。
实现协议的类定义这些方法的实现，来执行真正的操作。
另一种定义高度抽象类型的方法，是定义抽象基类。
通过抽象基类，我们可以生成一些其他子类可以共享的默认行为。
时间仓促，只学习了一些设计模式的概念。但是感觉受益不小。希望和我一样学习设计模式的同学可以多多交流，共同进步！
参考:
《Object-C编程之道（iOS设计模式解析）》人民邮电出版社