第三周学习总结

第三周 代码重构



面向对象的设计模式





设计模式的定义



设计模式是一种可重复使用的解决方案。每一种模式都描述了一种问题的通用解决方案，这种问题在我们的环境中不断出现。掌握设计模式需要关注每个设计模式的四个部分：



• 模式的名称：它是由少量的字组成的名称，有助于我们表达我们的设计

• 待解问题：描述了何时需要运用这种模式，以及运用模式的环境（上下文）

• 解决问题：描述了组成设计的元素（类和对象）、它们的关系、职责以及合作。但这种解决方案是抽象的，它不代表具体的实现。所以设计模式是不限定于具体的编程语言的。

• 结论：运用这种方案所带来的利和弊。主要是指它对系统的弹性、扩展性和可移植性的影响。



设计模式的分类



按功能分类



• 创建模式（Creational Patterns）：对类的实例化过程的抽象。



> 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

>

> 包括有：

>

> > - 工厂模式（Factory Pattern）

> > - 抽象工厂模式（Abstract Factory Pattern）

> > - 单例模式（Singleton Pattern）

> > - 建造者模式（Builder Pattern）

> > - 原型模式（Prototype Pattern）



• 结构模式（Structural Patterns）： 将类或者对象结合在一起形成更大的结构



> 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。

>

> 包括：

>

> > - 适配器模式（Adapter Pattern）

> > - 桥接模式（Bridge Pattern）

> > - 过滤器模式（Filter、Criteria Pattern）

> > - 组合模式（Composite Pattern）

> > - 装饰器模式（Decorator Pattern）

> > - 外观模式（Facade Pattern）

> > - 享元模式（Flyweight Pattern）

> > - 代理模式（Proxy Pattern）



• 行为模式（Behavioral Patterns）：对在不同的对象之间划分责任和算法的抽象化



> 这些设计模式特别关注对象之间的通信。

>

> 包括：

>

> > - 责任链模式（Chain of Responsibility Pattern）

> > - 命令模式（Command Pattern）

> > - 解释器模式（Interpreter Pattern）

> > - 迭代器模式（Iterator Pattern）

> > - 中介者模式（Mediator Pattern）

> > - 备忘录模式（Memento Pattern）

> > - 观察者模式（Observer Pattern）

> > - 状态模式（State Pattern）

> > - 空对象模式（Null Object Pattern）

> > - 策略模式（Strategy Pattern）

> > - 模板模式（Template Pattern）

> > - 访问者模式（Visitor Pattern）



按方式分类



• 类模式：以继承的方式实现模式，静态的。

• 对象模式：以组合的方式实现模式，动态的。



简单工厂模式



工厂模式解决的问题是如何创建一系列相关的对象， 而无需指定其具体类。课程中基于排序算法需求讨论了几种工厂模式来解决排序算法、比较器、数据容器的创建和管理。为了更好的实现OCP原则，我们采用动态编程（反射）方式实现工厂模式，将运行时需要用的具体算法、比较器、数据容器的实现以配置文件的形式传递控制创建过程。这种方式满足了OCP原则，但会带来一些缺点需要注意和取舍：



• 缺少编译期类型安全检查

• 限制了Sorter的实现，只能是通过默认构造函数来创建



单例模式



Singleton 模式保证产生单一实例，就是说一个类只产生一个实例。使用 singleton 有两个原因：



• 是因为只有一个实例，可以减少实例频繁创建和销毁带来的资源消耗；

• 是当多个用户使用这个实例的时候，便于进行统一控制（比如打印机对象）。



前者是性能需求，后者是功能需求。



在Java中，有多种方式实现单例，有Eager initializtion、statc block initializtion lazy initialization、Thread safe Singleto、Bill Pugh Singleton Implementation和Enum Singleton， 具体的可以参考文章Java Singleton Design Pattern Best Practices with Examples文章，还提到了单例模式在反射编程中容易被破坏的一些问题，包括分布式场景下，序列化和反序列化单例实例的问题。



适配器模式



适配器模式（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 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。



使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。



注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。



模板方法模式



在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。



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



主要解决：一些方法通用，却在每一个子类都重新写了这一方法。



何时使用：有一些通用的方法。



如何解决：将这些通用算法抽象出来。



关键代码：在抽象类实现，其他步骤在子类实现。



应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。



优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。



缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。



使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。



注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。



策略模式



在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。



在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。



意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。



主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。



何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。



如何解决：将这些算法封装成一个一个的类，任意地替换。



关键代码：实现同一个接口。



应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。



优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。



缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。



使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。



注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。



组合模式



组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。



这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。



意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。



主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。



何时使用： 1、您想表示对象的部分-整体层次结构（树形结构）。 2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。



如何解决：树枝和叶子实现统一接口，树枝内部组合该接口。



关键代码：树枝内部组合该接口，并且含有内部属性 List，里面放 Component。



应用实例： 1、算术表达式包括操作数、操作符和另一个操作数，其中，另一个操作符也可以是操作数、操作符和另一个操作数。 2、在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。



优点： 1、高层模块调用简单。 2、节点自由增加。



缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。



使用场景：部分、整体场景，如树形菜单，文件、文件夹的管理。



注意事项：定义时为具体类。



装饰器模式



装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。



这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。



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



主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。



何时使用：在不想增加很多子类的情况下扩展类。



如何解决：将具体功能职责划分，同时继承装饰者模式。



关键代码： 1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。



应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。



优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。



缺点：多层装饰比较复杂。



使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。



注意事项：可代替继承。