设计模式 6大原则.pdf

目 录 空白目录 本文档使用 看云 构建 - 2 - 空白目录 空白目录 设计模式 标签 （空格分隔 ）： 设计模式 #设计模式六大原则 ##单一职责原则 就一个类而言 ，应该仅有一个引起它变化的原因。 所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变 ，那么这个类就具有多于一个的职责。而单一 职责原则就是指一个类或者模块应该有且只有一个改变的原因。 一个类 ，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线 ，如果一个类有一个 以上的职责 ，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时 ，可能会影响其它的职 责。另外 ，多个职责耦合在一起 ，会影响复用性。例如 ：要实现逻辑和界面的分离 此原则的核心就是解耦和增强内聚性。 public class Shape { var length:int; var width:int; public function Shape(length:int,width:int) { this.length length; this.width width; } public function draw():Sprite{ var huabu:Sprite new Sprite(); huabu.graphics.beginFill(0xFFee00); huabu.graphics.drawRect(20,20,length,width); huabu.graphics.endFill(); return huabu; } public function area():int{ return width*length; } } Shape类拥有两个方法 ，一个方法是draw用来画图形 ，一个方法是area用来计算面积。 因此它有两个原则 ：计算面积和绘制图形 ，违背的单一职责原则。 绘制图形会与用户界面有关 ，但是计算图形面积却未必与界面有关 ，如果把这两个职责写到一个类中 ，那么如果 只需要使用area （）方法这一职责来计算面积 ，那就不得不把draw()方法一同编译 ，但是却可能也用不到它。 本文档使用 看云 构建 - 3 - 空白目录 如果其中一个职责需要修改 ，就不得不重新编译和部署另外一个。 还有一个例子 ：例如我们在设计游戏的时候 ，游戏界面和游戏逻辑是明显的两种职责 ，如果将游戏的逻辑和界面 写在同一个类中 ，可能当我们修改游戏窗口时会影响到逻辑部分的代码 ，或者当我们要把web端转移到手机端的 时候 ，界面的代码肯定是不能复用了 ，但是游戏逻辑的代码是可以复用的(例如俄罗斯方块) ，这样进行单一职责 划分 ，还有利于代码的复用。平时我们使用的MVC模式也是单一职责的典范 如果一个类承担的职责过多 ，就等于把这些职责偶合在一起 ，一个职责的变化可能会削弱或者抑制这个类完成其 他职责的能力。这种耦合会导致脆弱的设计 ，当变化发生时 ，设计会遭受到意想不到的破坏。 软件设计真正要做的许多内容 ，就是发现那些职责相互分离 ，如果你能够想到多于一个的动机去改变一个类 ，那 么这个类就具有多于一个的职责 ，就应该考虑职责分离 职责的划分就需要依据项目的大小和需求 ，例如在小枪的数据分析后台中 ，目前分为路由 ，数据处理 ，数据获 取。其中数据获取就是一个从postgreSQL中拉取各类数据的一个类 ，但是目前这个类中的代码已经接近于1000 行 ，有用户的登录数据 ，战斗数据 ，资源数据 ，修改获取用户的登录数据的时候可能会影响到其他数据 ，这时候 就可以对数据获取进行职责的详细划分 ，将本来的职责T ，细分为T1 ，T2 ，T3