《大话设计模式》笔记

1. 简单工厂模式

1.1 面向对象的好处

考虑通过封装、继承、多态把程序的耦合度降低，使用设计模式使得程序更加的灵活，容易修改，并且易于复用。

1.2 复制 Vs 复用

有人说初级程序员的工作就是 Ctrl+C 和 Ctrl+V，这其实是非常不好的编码习惯，因为当你的代码中重复的代码多到一定程度，维护的时候，可能就是一场灾难。越大的系统，这种方式带来的问题越严重，编程有一原则，就是用尽可能的办法去避免重复。

1.3 业务的封装

就是让业务逻辑与界面逻辑分开，让他们之间的耦合度下降。只有分离开，才可以达到容易维护或扩展。

1.4 紧耦合 Vs 松耦合

紧耦合就是模块或者系统之间关系太紧密，存在相互调用。紧耦合系统的缺点在于更新一个模块的结果导致其它模块的结果变化，难以重用特定的关联模块。

打个比方，如果现在公司要求你为公司的薪资管理系统做维护，原来只有技术人员（月薪），市场销售人员（底薪+提成），经理（年薪+股份）三种运算算法，现在要增加兼职工作人员（时薪）的算法，但按照你昨天的程序写法，公司就必须要把包含原三种算法的运算类给你，让你修改，你如果心中小算盘一打，‘TMD，公司给我的工资这么低，我真是郁闷，这下有机会了’，于是你除了增加了兼职算法以外，在技术人员（月薪）算法中写了一句 if(员工是小菜){salary = salary *1.1;}

那就意味着，你的月薪每月都会增加10%（小心被抓去坐牢），本来是让你加一个功能，却使得原有的运行良好的功能代码产生了变化，这个风险太大了。你明白了吗？”

1.5 简单工厂模式

简单工厂模式概述

到底要实例化谁，将来会不会增加实例化对象，应该考虑用一个单独的类来做这个创造实例的过程。这就是工厂，定义的这个工厂类负责创建一些类的实例。
优点

客户端不需要再负责对象的创建，从而明确了各个类的职责。
缺点

这个静态工厂类负责所有对象的创建，如果有新的对象增加，或者某些对象的创建方式不同，就需要不断的修改工厂类，不利于后期的维护。

2. 商场促销— 策略模式

在策略模式中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。在策略模式中，我们创建表示各种策略的对象一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

2.1 策略模式结构图

在这里插入图片描述

// 简单工厂模式的用法
CashSuper csuper = CashFactory.createCashAccept(cbxType.SelectedItem.ToString());

...=csuper.GetResult(...)
    
// 策略模式与简单工厂结合的用法
CashContext csuper = new CashContext(cbxType.SelefctedItem.ToString());

...=csuper.GetResult(...);

简单工厂模式相当于需要让客户端认识两个类，CashSuper 和 CashFactory，而策略模式与简单工程结合的用法，客户端就只需要认识一个类 CashContext 就可以了。耦合度更加降低。

2.2 策略模式解析

回过头来反思一下策略模式，策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。

“策略模式还有些什么优点？”

策略模式的Strategy类层次为Context定义了一系列可供重用的算法或行为。继承有助于析取出这些算法中的公共功能[DP]。对于打折、返利或者其他的算法，其实都是对实际商品收费的一种计算方式，通过继承，可以得到它们的公共功能。

“公共的功能就是获得计算费用的结果GetResult，这使得算法间有了抽象的父类CashSuper。”

策略模式的另一个优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

“每个算法可保证它没有错误，修改其中任一个时也不会影响其他的算法。”

当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为。将这些行为封装在一个个独立的Strategy类中，可以在使用这些行为的类中消除条件语句。策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

3. 单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

“这下你知道你的手机为什么不能拍摄好UFO的原因了吧？”大鸟笑道。

“如果手机只用来接听电话，DV用来拍摄，职责的分离是可以把事情做得更好。不过这其实不是一回事哦，现在的智能手机承担的职责多，并不等于就不可以做好，只不过现在的科技还不能让手机在摄像时超过DV而已。”小菜分析说。

“整合当然是一种很好的思想。比如Google最初的理想就是将一切的需求都整合到一个文本框里提交，用干净的页面来吸引用户，导致互联网的一场变革。但现在分类信息、垂直搜索又开始流行，这却是单一职责的思想体现。现在智能手机整合了很多功能的原因是因为DV、DC、MP3等产品的体积也太大了。手机携带很方便，所以才有了这样的过渡产品，如果，每一样数码产品都缩小100倍，就像放在包里的一张卡片、一支笔那么简单，而功能和质量都不发生变化，你还会觉得它们很麻烦吗？”大鸟总结道，“总的来说，手机的发展有它的特点，而编程时，我们却是要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。”

4. 开放-封闭原则

开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

这个原则其实是有两个特征，一个是说’对于扩展是开发的（Open for extension）‘，另一个是说’对于更改是封闭的（Closed for modification）’

我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？

也就是说，设计软件要容易维护又不出问题的最好办法，就是多扩展，少修改。你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。

绝对的对修改关闭是不可能的。无论模块是多么的’封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最优可能发生的变化种类，然后构造抽象类隔离那些变化。

在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动。在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

即面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。 这就是’开放-封闭原则’的精神所在。同时，开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

5. 依赖倒转原则

5.1 依赖倒转原则

抽象不应该依赖细节，细节应该依赖于抽象， 说白了，就是要针对接口编程，不要对实现编程，无论主板、CPU、内存、硬盘都是在针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，那就会出现换内存需要把主板也换了的尴尬。

依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有依赖关系都是终止于抽象类或者接口，即面向对象的设计，反之那就是过程化的设计了。

5.2 里式替换原则

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

6. 装饰模式

装饰模式（Decorator），动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
在这里插入图片描述

Component是定义一个对象接口，可以给这些对象动态地添加职责。ConcreteComponent是定义了一个具体的对象，也可以给这个对象添加一些职责。Decorator，装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。

装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为。这种做法的问题在于，它们在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度。而装饰模式却提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象。因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。

7. 代理模式

代理模式（Proxy），为其他对象提供一种代理以控制对这个对象的访问。

代理模式（Proxy）结构图
在这里插入图片描述

一、远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。
二、虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。这样就可以达到性能的最优化，比如你打开一个很大的HTML页面时，里面可能有很多的文字和图片，但你还是可以很快打开它，此时你所看到的是所有的文字，但图片却是一张一张地下载后才能看到。那些未打开的图片框，就是通过虚拟代理来替代了真实的图片，此时代理存储了真实图片的路径和尺寸。
三、安全代理，用来控制真实对象访问时的权限。一般用于对象应该有不同的访问权限的时候。
四、智能指引，是指当调用真实的对象时，代理处理另一些事。如计算真实对象的引用次数，这样当该对象没有引用时，可以自动释放它；或当第一次引用一个持久对象时，将它装入内存；或在访问一个实际对象前，检查是否已经锁定它，以确保其他对象不能改变它。它们都是通过代理在访问一个对象时附加一些内务处理。

8. 工厂方法模式

简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了具体产品的依赖。

工厂方法模式（Factory Method）结构图
在这里插入图片描述

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在是修改客户端。

9. 原型模式

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

原型模式（Prototype）结构图
在这里插入图片描述

原型模块其实就是从一个对象再创建另外一个可定制的对象，而且不需知道任何创建的细节。

一般在初始化的信息不发生变化的情况下，克隆是最好的办法。既隐藏了对象创建的细节，又对性能是大大的提高。它等于是不用重新初始化对象，而是动态地获得对象运行时的状态。

9.1 浅复制与深复制

浅复制：被复制对象的所有变量都含有与原来的对象相同的值，而所有的对其他对象的引用都仍然指向的对象。

深复制：把引用对象的变量指向复制过的新对象，而不是原有的被引用的对象。

10. 模板方法模式

模板方法模式，定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

模板方法模式（TemplateMethod）结构图
在这里插入图片描述

AbstractClass是抽象类，其实也就是一抽象模板，定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。
在这里插入图片描述

ConcreteClass，实现父类所定义的一个或多个抽象方法。每一个 AbstractClass都可以有任意多个 ConcreteClass与之对应，而每一个ConcreteClass都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。

在这里插入图片描述

10.1 模板方法模式特点

模板方法模式是通过把不变行为搬移到超类，去除子类的重复代码来体现它的优势。

模板方法模式就是提供了一个很好的代码复用平台。因为有时候，我们会遇到由一系列步骤构成的过程需要执行。这个过程从高层次上看是相同的，但有些步骤的实现可能不同。这时候，我们通常就应该要考虑用模板方法模式了。

当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中重复出现。我们通过模板方法模式把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠。

11. 迪米特法则

迪米特法则（Lod）也叫最少知识原则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的 private 状态，不需要让别的类知道的字段或行为就不要公开。"

迪米特法则其根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。

12. 外观模式

外观模式（Facade），为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

外观模式（Facade）结构图
在这里插入图片描述

“对于面向对象有一定基础的朋友，即使没有听说过外观模式，也完全有可能在很多时候使用它，因为它完美地体现了依赖倒转原则和迪米特法则的思想，所以是非常常用的模式之一。”

12.1 何时使用外观模式

首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。**其次，在开发阶段，子系统往往因为不断重构演化而变得越来越复杂，**大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。第三，在维护一个遗留的大型系统时，可能这个系统非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。
在这里插入图片描述

13. 建造者模式

如果你需要将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示的意图时，我们需要应用与一个设计模式，‘建造者（Builder）模式’，又称为生成器模式。

建造者模式可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。如果我们用了建造者模式，那么用户就只需指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。

建造者模式（Builder），将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式（Builder）结构图
在这里插入图片描述

“它主要是用于创建一些复杂的对象，这些对象内部构建的建造顺寻通常时稳定的，但对象内部的构建通常面临着复杂的变化。”

“建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品时如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体就可以了。”

14. 观察者模式

观察者模式又叫做发布-订阅（Publish/Subscribe）模式。

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

观察者模式（Observer）结构图
在这里插入图片描述

14.1 观察者模式特点

将一个系统分割成一系列相互协作的类有一个很不好的辅作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。

当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。

当一个抽象模型有两个方面，其中一方面依赖与另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。

观察者所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

15. 抽象工厂模式

抽象工厂模式（Abstract Factory），提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。

抽象工厂模式（Abstract Factory）结构图
在这里插入图片描述

15.1 抽象工厂模式的优点与缺点

最大的 好处便是易于交换产品系列，由于具体工厂类，例如 IFactory factory = new AccessFactory()，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。第二大好处是，它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

16. 状态模式

状态模式（State），当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

状态模式（State）结构图
在这里插入图片描述

17. 适配器模式

适配器模式（Adapter），将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

在软件开发中，也就是系统的数据和行为都正确，但接口不符时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器开模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况，比如在需要对早期代码复用一些功能等应用上很有实际价值。

在这里插入图片描述

18. 备忘录模式

备忘录（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

在这里插入图片描述
Memento模式比较适用与功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态。

19. 组合模式

组合模式（Composite），将对象组合成树形结构以标识 '部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
在这里插入图片描述

19.1 透明方式与安全方式

树可能有无数的分枝，但只需要反复用 Composite 就可以实现树状结构了。这种方式叫做透明方式，也就是说在Component中声明所有用来管理子对象的方法，其中包括Add、Remove等。这样实现Component 接口的所有子类都具备了 Add 和 Remove。这样做的好处就是叶结点和枝节点对于外界没有区别，它们具备完全一致的行为接口。但问题也很明显，因为Leaf类本身不具备Add()、Remove()方法的功能，所以实现它是没有意义的。

也可以在Leaf类当中不用 Add 和 Remove 方法，那么就需要安全方式，也就是在Component接口中不去声明Add和Remove方法，那么子类的Leaf也就不需要去实现它，而是在Composite声明所有用来管理子类对象的方法，不过由于不够透明，所以树叶和树枝类将不具有相同的接口，客户端的调用需要做相应的判断，带来了不便。