大话的设计模式总结.doc

UML类图 ?在UML类图中，常见的有以下几种关系:?泛化（Generalization）,??实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。 1.?泛化（Generalization） 【泛化关系】是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头及指向】带三角箭头的实线，箭头指向父类。 泛化 实现 2.?实现（Realization） 【实现关系】是一种类与接口的关系，表示类是接口所有特征和行为的实现。 【箭头及指向】带三角箭头的虚线，箭头指向接口。 3.?关联（Association) 【关联关系】是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】成员变量 【箭头及指向】带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。? 下图为自身关联：? ?4.?聚合（Aggregation） 【聚合关系】是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。 聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。 【代码体现】成员变量 【箭头及指向】带空心菱形的实心线，菱形指向整体 聚合 组合 5.?组合(Composition) 【组合关系】是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。 组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。 【代码体现】成员变量 【箭头及指向】带实心菱形的实线，菱形指向整体 ??6.?依赖(Dependency) 【依赖关系】是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖. 【代码表现】局部变量、方法的参数或者对静态方法的调用 【箭头及指向】带箭头的虚线，指向被使用者 各种关系的强弱顺序：泛化?=?实现??组合??聚合??关联??依赖? 下面这张UML图，比较形象地展示了各种类图关系： 参考资料：/tianhai110/article/details/6339565 设计模式之重要原则 单一职责原则（SRP） 就一个类而言，应该仅有一个引起它变化的原因。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化变化可能会削弱或抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。 开放-封闭原则 是说软件实体（类、模块、函数等）应该可以扩展，但是不可修改。也就说，对于扩展是开放的(Open for extension)，对于更改是封闭的(Closed for modification). 无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最具有可能发生的变化种类，然后构造抽象来隔离那些变化。等到变化发生时立即采取行动。 在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。 开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。 依赖倒转原则 高层模块不应该依赖低层模块。两个都应该依赖抽象。 抽象不应该依赖细节。细节应该依赖抽象。 里氏代换原则 子类型必须能够替换掉它们的父类型。 一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。 迪米特法则（最少知