读

   设计模式提高代码复用性，对框架性代码把握更强，直观的把握代码脉络和走势。设计模式，亦框架，把握框架，再填充实现，即完成设计。

全书很薄，思路却很清晰，因为之前读Android的Binder不太明朗，后才知此为Proxy代理模式，构造性很强。并没有《设计模式那点事》深入，但写到的一些遵循规则还是很有借鉴的，写下来以便后来查阅。

一.针对接口编程，不要针对实现编程。

二.单一职责原则 

MVC

三.开放封闭原则：对实现封闭，对接口开放

已有应用简介： 
开放封闭原则是所有面向对象原则的核心。
软件的分析、设计、编码、维护等生命周期的各个阶段总是力求做到对修改关闭、对扩展开放。
著名的巴巴运动网生命周期的各个阶段就遵循了开放封闭原则。它把基本的 CRUD 操作做成了一个接口，同时采用了 JDK 
5 引入的泛型技术，这样就可以保证以后做基本的添删改查操作时只需要实现该类即可。但由于引入了泛型技术，同时
在后台提供了对接口的抽象实现，你甚至不用写一行代码，就可以自如的操作数据库。如果以后又需要扩展的地方，只
需要扩展继承扩展自己的特有的操作即可，大大提高了生产效率。

四.里氏代换原则

定义：       
里氏代换原则（Liskov Substitution Principle）是指：一个软件实体如果使用的是基类的话，那么也一定适用于其子
类，而且它根本觉察不错使用的是基类对象还是子类对象；反过来的代换这是不成立的，即：如果一个软件实体使用一
个类的子类对象，那么它不能够适用于基类对象。

法海要做的就是不管你是什么妖魔，只要是妖魔我就要把你收服，以防再次出来危害人间。他并不用区分你是蛇妖
还是狐妖，更不用管你蛇妖中的青蛇还是白色。
凡是对妖魔这个基类适用的  白蛇、青蛇就全部适用。

五.迪米特法则

定义： 
迪米特法则(Law of Demeter，简写 LoD )又叫做最少知识原则（LeastKnowledge Principle  简写 LKP），也就是说，
一个对象应当对其他对象尽可能少的了解，不和陌生人说话。

迪米特法则的目的在于降低类与类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模
块功能独立，是的相互间存在尽可能少的依赖关系。
在运用迪米特法则到系统的设计中时,要注意以下几点:
第一：在类的划分上，应当创建弱耦合的类，类与类之间的耦合越弱，就越有利于实现可复用的目标。
第二：在类的结构设计上，每个类都应该降低成员的访问权限。 
第三：在类的设计上，只要有可能，一个类应当设计成不变的类。
第四：在对其他类的应用上，一个对象对其他类的对象的应用应该降到最低。
第五：尽量限制局部变量的有效范围。

但是过度使用迪米特法则，也会造成系统的不同模块之间的通信效率降低，使系统的不同模块之间不容易协调等缺点。
同时，因为迪米特法则要求类与类之间尽量不直接通信，如果类之间需要通信就通过第三方转发的方式，这就直接导致
了系统中存在大量的中介类，这些类存在的唯一原因是为了传递类与类之间的相互调用关系，这就毫无疑问的增加了系
统的复杂度。解决这个问题的方式是：使用依赖倒转原则（通俗的讲就是要针对接口编程，不要针对具体编程），这要
就可以是调用方和被调用方之间有了一个抽象层，被调用方在遵循抽象层的前提下就可以自由的变化，此时抽象层成了
调用方的朋友。
如下图所示：
故事分析：

温馨提示： 
迪米特法则是一种面向对象系统设计风格的一种法则，尤其适合做大型复杂系统设计指导原则。但是也会造成系统的不
同模块之间的通信效率降低，使系统的不同模块之间不容易协调等缺点。同时，因为迪米特法则要求类与类之间尽量不
直接通信，如果类之间需要通信就通过第三方转发的方式，这就直接导致了系统中存在大量的中介类，这些类存在的唯
一原因是为了传递类与类之间的相互调用关系，这就毫无疑问的增加了系统的复杂度。解决这个问题的方式是：使用依
赖倒转原则（通俗的讲就是要针对接口编程，不要针对具体编程），这要就可以是调用方和被调用方之间有了一个抽象
层，被调用方在遵循抽象层的前提下就可以自由的变化，此时抽象层成了调用方的朋友。

六.合成聚合复用原则 

合成复用原则跟简洁的表述是：要尽量使用合成和聚合，尽量不要使用继承。

聚合（Aggregation）是关联关系的一种，用来表示一种整体和部分的拥有关系。整体持有对部分的引用，可以调用部
分的能够被访问的方法和属性等，当然这种访问往往是对接口和抽象类的访问。作为部分可以可以同时被多个新的对象
引用，同时为多个新的对象提供服务。
合成（Composition）也是关联关系的一种，但合成是一种比聚合强得多的一种关联关系。在合成关系里面，部分和整
体的生命周期是一样的。作为整体的新对象完全拥有对作为部分的支配权，包括负责和支配部分的创建和销毁等，即要
负责作为部分的内存的分配和内存释放等。从这里也可以看出来，一个合成关系中的成员对象是不能喝另外的一个合成
关系共享的。
为何“要尽量使用合成和聚合，尽量不要使用继承”呢？这是因为：第一，继承复用破坏包装，它把超类的实现细节直接
暴露给了子类，这违背了信息隐藏的原则；第二：如果超类发生了改变，那么子类也要发生相应的改变，这就直接导致
了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。而是用合成和聚合的时候
新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新
的类专注于实现自己的任务，符合单一职责原则.

七.工厂模式

简单工厂模式解释：
简单工厂模式（Simple Factory Pattern）属于类的创新型模式，又叫静态工厂方法模式（Static FactoryMethod 
Pattern）,是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

九.单例模式

单例模式解释：
GoF 对单例模式(Singleton Pattern)的定义是：保证一个类、只有一个实例存在，同时提供能对该实例加以访问
的全局访问方法。
单例模式是一种对象创建型模式，使用单例模式，可以保证为一个类只生成唯一的实例对象。也就是说，在整个程
序空间中，该类只存在一个实例对象。
单例模式的要点有三个；一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统
提供这个实例。

十.原型模式

原型模式解释：
原型模式（Prototype Pattern）是一种对象创建型模式，它采取复制原型对象的方法来创建对象的实例。使用
Prototype 模式创建的实例，具有与原型一样的初始化数据

原型模式使用场景分析及代码实现：
在上面的使用场景中，因为 GG 打字太慢经常被女朋友怪罪，所以有了拷贝网上肉麻情话的和主要聊天话题内容的
办法。这样，以后 GG 每次和 MM 聊天的时候只需要把原话拷贝出来，加以适当修改就行，省时省力，而且效果绝佳^_^，
这就是设计模式的原型模式的使用的好处 O(∩_∩)O~
UML 模型图如下所示：

原型对象一般在适用于一下场景：
在创建对象的时候，我们不仅希望被创建的对象继承其类的基本机构，而且还希望继承原型对象的数据。
希望对目标对象的修改不影响既有的原型对象（深度克隆的时候可以完全互不影响）。