设计模式首篇

墨蓝 2021-10-23 12:42 287阅读 0赞

首先说设计模式六大法则：  
1.单一原则（Single Responsibility Principle）：一个类只负责一项职责，尽量做到类的只有一个行为原因引起变化；  
　　a、业务对象（BO business object）、业务逻辑（BL business logic）拆分；  
2.里氏替换原则（LSP liskov substitution principle）：子类可以扩展父类的功能，但不能改变原有父类的功能；  
通俗来说在软件里，可以把子类都替换为父类，程序的行为没有变化。　  
3.依赖倒置原则（dependence inversion principle）：面向接口编程；（通过接口作为参数实现应用场景）抽象就是接口或者抽象类，细节就是实现类含义：  
　　　　上层模块不应该依赖下层模块，两者应依赖其抽象；  
　　　　抽象不应该依赖细节，细节应该依赖抽象；  
4.接口隔离（interface segregation principle）：建立单一接口；（扩展为类也是一种接口，一切皆接口）  
　　　定义：  
　　　　a.客户端不应该依赖它不需要的接口；  
　　　　b.类之间依赖关系应该建立在最小的接口上；  
　【接口的设计粒度越小，系统越灵活，但是灵活的同时结构复杂性提高，开发难度也会变大，维护性降低】　　　  
5.迪米特原则（law of demeter LOD）：最少知道原则，尽量降低类与类之间的耦合；  
6.开闭原则（open closed principle）：对扩展是开放的，对修改是关闭的。允许新增，不允许修改。

**1.简单工厂模式**  
1 工厂模式的作用，为什么要用工厂模式？  
工厂模式是为了解耦：把对象的创建和使用的过程分开。就是Class A 想调用Class B,那么只是调用B的方法，而至于B的实例化，就交给工厂类。  
工厂模式可以降低代码重复。如果创建B过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。可以把这些创建对象B的代码放到工厂里统一管理。既减少了重复代码，也方便以后对B的维护。  
工厂模式可以减少错误，因为工厂管理了对象的创建逻辑，使用者不需要知道具体的创建过程，只管使用即可，减少了使用者因为创建逻辑导致的错误。  
2.工厂模式的一些适用场景：  
对象的创建过程/实例化准备工作很复杂，需要很多初始化参数，查询数据库等  
类本身有好多子类，这些类的创建过程在业务中容易发生改变，或者对类的调用容易发生改变。  
**2工厂模式**  
简单工厂模式是把返回对象的逻辑写到了工厂里，根据传入参数的不同，返回不同的对象。工厂模式是创建很多工厂类，直接创建工厂对象，在根据工厂对象生成对象。  
**3抽象工厂模式**  
抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。  
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。  
介绍  
意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。  
主要解决：主要解决接口选择的问题。  
何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。  
如何解决：在一个产品族里面，定义多个产品。  
关键代码：在一个工厂里聚合多个同类产品。  
应用实例：工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OOP 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。  
优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。  
缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。  
使用场景： 1、QQ 换皮肤，一整套一起换。 2、生成不同操作系统的程序。  
注意事项：产品族难扩展，产品等级易扩展。  
**4原型模式**  
原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。  
这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。  
介绍  
意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。  
主要解决：在运行期建立和删除原型。  
何时使用： 1、当一个系统应该独立于它的产品创建，构成和表示时。 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。 3、为了避免创建一个与产品类层次平行的工厂类层次时。 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。  
如何解决：利用已有的一个原型对象，快速地生成和原型对象一样的实例。  
关键代码： 1、实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。 2、原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些"易变类"拥有稳定的接口。  
应用实例： 1、细胞分裂。 2、JAVA 中的 Object clone() 方法。  
优点： 1、性能提高。 2、逃避构造函数的约束。  
缺点： 1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。  
使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。  
注意事项：与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。  
**5策略模式**  
在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。  
介绍  
意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。  
主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。  
何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。  
如何解决：将这些算法封装成一个一个的类，任意地替换。  
关键代码：实现同一个接口。  
应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。  
优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。  
缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。  
使用场景：  
1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。  
2、一个系统需要动态地在几种算法中选择一种。  
3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。  
注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。  
**6.装饰者模式**  
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。  
意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。  
主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。  
何时使用：在不想增加很多子类的情况下扩展类。  
如何解决：将具体功能职责划分，同时继承装饰者模式。  
关键代码： 1、Component 类充当抽象角色，不应该具体实现。  
2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。  
应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。  
2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。  
优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。  
缺点：多层装饰比较复杂。  
使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。  
注意事项：可代替继承。  
**7建造者模式**  
建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。  
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。  
介绍  
意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。  
主要解决：主要解决在软件系统中，有时候面临着"一个复杂对象"的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。  
何时使用：一些基本部件不会变，而其组合经常变化的时候。  
如何解决：将变与不变分离开。  
关键代码：建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。  
应用实例： 1、去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的"套餐"。 2、JAVA 中的 StringBuilder。  
优点： 1、建造者独立，易扩展。 2、便于控制细节风险。  
缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。  
使用场景： 1、需要生成的对象具有复杂的内部结构。 2、需要生成的对象内部属性本身相互依赖。  
注意事项：**与工厂模式的区别是：建造者模式更加关注与零件装配的顺序**。

**8适配器模式**  
适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。  
这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。  
意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。  
主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。  
何时使用： 1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）  
如何解决：继承或依赖（推荐）。  
关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。  
应用实例： 1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。  
优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。  
缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。  
使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。  
注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。