设计模式

🚏 导论 单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。 🎬 场景 场景一：📱 手机 现在的手机都有很多功能（除了打电话、发消息）：听音乐 、玩游戏、 拍照、摄影等等。但是这里的功能，都是基础功能，实际并没有做的特别专。比如听音乐，手机的音质没有专业的音乐播放器好；拍照，手机的像素没有专业的相机好；玩游戏，手机的操作体验没有专业的游戏机好。所以，手机的功能虽然多，但是都是基础功能，没有做的特别专业。大多时候，一件产品简单一些，职责单一一些，或许是更好的选择。 当然，手机的发展有它的特点，而编程时，我们却是要在类的职责分离上多做思考，做到单一职责，这样代码才是真正的易维护、易扩展、易复用、灵活多样。 场景二：♦️ 俄罗斯方块 俄罗斯方块的实现：俄罗斯方块下落动画的原理是画四个小方块，擦掉，然后再在下一行画四个小方块。不断绘出和擦掉就形成了动画，所以应该要有画和擦方块的动画。然后左右键实现左移和右移，下键实现加速，上键实现旋转，这些其实都应该是函数，当然左右移动需要考虑碰撞的问题，下移需要考虑堆积和消层的问题。 这里大部分都是一些函数，如果将这些函数都放在一个类里，那么这个类就会变得很大，很难维护并且也很难迁移。可以将这些与游戏逻辑相关的函数（下落、旋转、碰撞判断、移动、堆积）提取出来，这些函数和界面如何表示没有特别大的关系，因为所谓方块无非是一个坐标，方块的下落、旋转、碰撞判断、移动、堆积等都是坐标的变化。因此可以将运行界面和游戏逻辑分开，这样就可以更好的维护和迁移。

🚏 导论 它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。可以用策略模式封装几乎任何类型的规则，只要分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这些变化的可能性。 🧀 前置知识 🚦 结构 UML 类图 classDiagram class Context{ -strategy: Strategy +Context(strategy: Strategy) +contextInterface() } class Strategy{ <<abstract>> +algorithmInterface() } class ConcreteStrategyA{ +algorithmInterface() } class ConcreteStrategyB{ +algorithmInterface() } class ConcreteStrategyC{ +algorithmInterface() } Context o-- Strategy Strategy <|-- ConcreteStrategyA Strategy <|-- ConcreteStrategyB Strategy <|-- ConcreteStrategyC 基本代码 Strategy类，定义所有支持的算法的公共接口。 public abstract class Strategy { /** * 算法方法 */ public abstract void algorithmInterface(); } ConcreteStrategy类，实现具体的算法。 class ConcreteStrategyA extends Strategy { @Override public void algorithmInterface() { System.out.println("算法A实现"); } } class ConcreteStrategyB extends Strategy { @Override public void algorithmInterface() { System.out.println("算法B实现"); } } class ConcreteStrategyC extends Strategy { @Override public void algorithmInterface() { System.out.println("算法C实现"); } } Context, 用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。 ...

🚏 导论 抽象工厂模式（Abstract Factory Pattern），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们的具体类。当有多个相同的类要实现类似的功能，但是具体的实现细节有所不同，这时候就可以使用抽象工厂模式。 🧀 前置知识 工厂方法模式（Factory Method） 🚦 结构 classDiagram class AbstractFactory{ <<interface>> +createProductA() +createProductB() } class ConcreteFactory1{ +createProductA() +createProductB() } class ConcreteFactory2{ +createProductA() +createProductB() } class AbstractProductA{ <<interface>> } class ProductA1 class ProductA2 class AbstractProductB{ <<interface>> } class ProductB1 class ProductB2 class Client AbstractFactory <|.. ConcreteFactory1 AbstractFactory <|.. ConcreteFactory2 AbstractProductA <|.. ProductA1 AbstractProductA <|.. ProductA2 AbstractProductB <|.. ProductB1 AbstractProductB <|.. ProductB2 Client --> AbstractFactory Client --> AbstractProductA Client --> AbstractProductB AbstractProductA和AbstractProductB是两个抽象产品，之所以抽象，是因为它们有可能有不同的实现，而ProductA1、ProductA2、ProductB1、ProductB2是对两个抽象产品的具体分类实现。 ...