iOS设计模式(一)

为什么学习设计模式

在明白为什么学习设计模式之前,这学期我第一次在学校上了软件工程这门课。

课上老师有一个思想和说法,令我耳目一新,改变了我原有对于软件开发的认识,大概意思是:

与建筑工程这类看的见的实体工程一样,我们的软件开发也是一项真正的工程。
我们需要结构的设计,来保证安全,美观,好用。也需要合理的分工,来达到最好的结果。

从此,我对待软件开发的学习态度也大不一样,我知道自己开发的不是什么随随便便的小东西——而是运用真正的科学技术,去开发的软件工程。

因此不应该盲目地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设计模式解析)》人民邮电出版社