大话设计模式 -摘要1

第一章

代码功能：用面向对象语言实现一个计算器控制台程序，要求输入两个数和运算符

注意事项：

1. 除数不为0

2. 符号可能输入错误

3. 应用面向对象思维

重   点：

1.简单计算器代码书写

2.简单的工厂模式

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例。

优点：

工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责"消费"对象就可以了。而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利，有利于整个软件体系结构的优化。

缺点：

由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。

使用场景

工厂类负责创建的对象比较少; 客户只知道传入工厂类的参数，对于如何创建对象(逻辑)不关心;由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。

3.面向对象

封装     把操作进行封装

继承     创造一个运算结果的父类，通过继承改变结果的运算

多态     运用简单的工程模式，进行多态处理

 

 

第二章

代码功能：做一个商场收银软件，营业员根据客户所购买的商品单价和数目，向客户收费

注意事项：

1. 可能存在打折情况

重   点：

1.简单收银代码书写

2.使用工厂模式，封装正常收费和打折收费的类

3.策略模式

应用场景:

1、 多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。

2、 需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。

3、 对客户隐藏具体策略(算法)的实现细节，彼此完全独立。

 

优点:

1、 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。

2、 策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。

3、 使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。

 

缺点:

1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

2、 策略模式造成很多的策略类，每个具体策略类都会产生一个新类。有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。

 

 

第三章

单一职责原则

应用场景:

单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。

 

 

第四章

开放-封闭原则

应用场景:

软件实体应该是可扩展，而不可修改的。

      开放封闭原则的意思是，设计的时候，时刻要考虑，尽量让这个类是足够好，写好了不要去修改了，若有新需求，增加一些类就完事，原来的代码能不动就不动。

 

 

第五章

依赖倒转原则

应用场景:

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B.抽象不应该依赖于具体，具体应该依赖于抽象。

    依赖倒转原则的意思是，针对接口编程而不对实现编程。

里氏代换原则

应用场景:

子类型必须能替换掉他们的父类型。

    简单的理解为一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，软件里面，把父类都替换成它的子类，程序的行为没有变化。

 

 

第六章

代码功能：可以换各种各样的衣服裤子的个人形象系统

注意事项：

1. 不能把每件衣服的函数写在人的类中

2. 需要把所需的功能按正常顺序串联起来进行控制

3. 内部组装完毕再显示

重   点：

1.简单衣服的类代码书写

2.装饰模式

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

使用场景：

1. 需要扩展一个类的功能，或给一个类添加附加职责。

2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。

3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。

4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

优点：

1. Decorator可以提供比继承更多的灵活性。

2. 通过使用不同的具体装饰类以及这些装饰类的排列组合

3. 有效的把类的核心职责和装饰功能区分开

缺点：

1.意味着更加多的复杂性。

2. 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。

3. 装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

 

第七章

代码功能：B替代A追求C

注意事项：

1. A不能直接认识C

2. 不能直接让B追求C，而忘记A

重   点：

1.让B使用A的方式追求C

2.代理模式

为其他对象提供一种代理以控制对这个对象的访问。

对象实现同一个接口,先访问代理类再访问真正要访问的对象。

组成:

抽象角色:通过接口或抽象类声明真实角色实现的业务方法。

代理角色:实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。

真实角色:实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。

使用场景：

1. 远程代理。

2. 虚拟代理。

3. 安全代理。

4. 智能指引。

      优点：

(1).职责清晰

真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。

(2).代理对象可以在客户端和目标对象之间起到中介的作用，这样起到了的作用和保护了目标对象的作用。

(3).高扩展性

 

 

第八章

代码功能：学雷锋做好事

注意事项：

1. 建立雷锋工厂

2. 建立不同的人群工厂

重   点：

1.工厂方法模式

定义一个用于创造对象的接口，让子类决定实例化哪一个类

工厂方法克服了简单工厂的违背开放封闭原则的缺点，又保持了封装对象创建过程的优点。

      优点：

可以使代码结构清晰，有效地封装变化。在编程中，产品类的实例化有时候是比较复杂和多变的，通过工厂模式，将产品的实例化封装起来，使得调用者根本无需关心产品的实例化过程，只需依赖工厂即可得到自己想要的产品。

对调用者屏蔽具体的产品类。如果使用工厂模式，调用者只关心产品的接口就可以了，至于具体的实现，调用者根本无需关心。即使变更了具体的实现，对调用者来说没有任何影响。

降低耦合度。产品类的实例化通常来说是很复杂的，它需要依赖很多的类，而这些类对于调用者来说根本无需知道，如果使用了工厂方法，我们需要做的仅仅是实例化好产品类，然后交给调用者使用。对调用者来说，产品所依赖的类都是透明的。

 

 

第九章

代码功能：写个简历类，可以设置属性，最终需要多分简历

重   点：

1.       节省客户端的设置过程

2.       浅复制 深复制

3.       原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

使用场景

Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节。

 

 

第十章

代码功能：甲乙两个学生抄作业

重   点：

1.       简化代码，因为甲乙作业只有答案不同，题目一样

2.       模板方法模式

在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中

使用场景：

1．  某些类的算法中，用了相同代码

2．  控制子类扩展，子类必须遵守算法规则

优点：

1.       通过将不变的行为搬移到超类，去除了子类中的重复代码

2.       有助于算法扩展

3.       符合开闭原则

     缺点：类的个数增加，设计更抽象