[转载]关于设计模式

https://refactoringguru.cn/design-patterns 稍作整理
文末有彩蛋

设计模式是什么

• 设计模式是软件设计中常见问题的典型解决方案。 它们就像能根据需求进行调整的预制蓝图， 可用于解决代码中反复出现的设计问题。
• 设计模式与方法或库的使用方式不同， 你很难直接在自己的程序中套用某个设计模式。 模式并不是一段特定的代码， 而是解决特定问题的一般性概念。 你可以根据模式来实现符合自己程序实际所需的解决方案。
• 人们常常会混淆模式和算法， 因为两者在概念上都是已知特定问题的典型解决方案。 但算法总是明确定义达成特定目标所需的一系列步骤， 而模式则是对解决方案的更高层次描述。 同一模式在两个不同程序中的实现代码可能会不一样。
• 算法更像是菜谱： 提供达成目标的明确步骤。 而模式更像是蓝图： 你可以看到最终的结果和模式的功能， 但需要自己确定实现步骤。

模式包含哪些内容？

大部分模式都有正规的描述方式， 以便在不同情况下使用。 模式的描述通常会包括以下部分：

• 意图部分简单描述问题和解决方案。
• 动机部分将进一步解释问题并说明模式会如何提供解决方案。
• 结构部分展示模式的每个部分和它们之间的关系。
• 在不同语言中的实现提供流行编程语言的代码， 让读者更好地理解模式背后的思想。

部分模式介绍中还列出其他的一些实用细节， 例如模式的适用性、 实现步骤以及与其他模式的关系。

模式的历史

谁发明了设计模式？ 这是一个很好的问题， 但也有点不太准确。 设计模式并不是晦涩的、 复杂的概念——事实恰恰相反。 模式是面向对象设计中常见问题的典型解决方案。 同样的解决方案在各种项目中得到了反复使用， 所以最终有人给它们起了名字， 并对其进行了详细描述。 这基本上就是模式被发现的历程了。

模式的概念是由克里斯托佛·亚历山大在其著作 《建筑模式语言》 中首次提出的。 本书介绍了城市设计的 “语言”， 而此类 “语言” 的基本单元就是模式。 模式中可能会包含对窗户应该在多高、 一座建筑应该有多少层以及一片街区应该有多大面积的植被等信息的描述。

埃里希·伽玛、 约翰·弗利赛德斯、 拉尔夫·约翰逊和理查德·赫尔姆这四位作者接受了模式的概念。 1994 年， 他们出版了 《设计模式： 可复用面向对象软件的基础》 一书， 将设计模式的概念应用到程序开发领域中。 该书提供了 23 个模式来解决面向对象程序设计中的各种问题， 很快便成为了畅销书。 由于书名太长， 人们将其简称为 “四人组 （Gang of Four， GoF） 的书”， 并且很快进一步简化为 “GoF 的书”。

此后， 人们又发现了几十种面向对象的模式。 “模式方法” 开始在其他程序开发领域中流行起来。 如今， 在面向对象设计领域之外， 人们也提出了许多其他的模式。

为什么以及如何学习设计模式？

或许你已从事程序开发工作多年， 却完全不知道单例模式是什么。 很多人都是这样。 即便如此， 你可能也在不自知的情况下已经使用过一些设计模式了。 所以为什么不花些时间来更进一步学习它们呢？

• 设计模式是针对软件设计中常见问题的工具箱， 其中的工具就是各种经过实践验证的解决方案。 即使你从未遇到过这些问题， 了解模式仍然非常有用， 因为它能指导你如何使用面向对象的设计原则来解决各种问题。
• 设计模式定义了一种让你和团队成员能够更高效沟通的通用语言。 你只需说 “哦， 这里用单例就可以了”， 所有人都会理解这条建议背后的想法。 只要知晓模式及其名称， 你就无需解释什么是单例。

关于模式的争议

设计模式自其诞生之初似乎就饱受争议， 所以让我们来看看针对模式的最常见批评吧。

一种针对不完善编程语言的蹩脚解决方案

通常当所选编程语言或技术缺少必要的抽象功能时， 人们才需要设计模式。 在这种情况下， 模式是一种可为语言提供更优功能的蹩脚解决方案。

例如， 策略模式在绝大部分现代编程语言中可以简单地使用匿名 （lambda） 函数来实现。

低效的解决方案

模式试图将已经广泛使用的方式系统化。 许多人会将这样的统一化认为是某种教条， 他们会 “全心全意” 地实施这样的模式， 而不会根据项目的实际情况对其进行调整。

不当使用

如果你只有一把铁锤， 那么任何东西看上去都像是钉子。

这个问题常常会给初学模式的人们带来困扰： 在学习了某个模式后， 他们会在所有地方使用该模式， 即便是在较为简单的代码也能胜任的地方也是如此。

设计模式分类

不同设计模式的复杂程度、 细节层次以及在整个系统中的应用范围等方面各不相同。 我喜欢将其类比于道路的建造： 如果你希望让十字路口更加安全， 那么可以安装一些交通信号灯， 或者修建包含行人地下通道在内的多层互通式立交桥。

最基础的、 底层的模式通常被称为惯用技巧。 这类模式一般只能在一种编程语言中使用。

最通用的、 高层的模式是构架模式。 开发者可以在任何编程语言中使用这类模式。 与其他模式不同， 它们可用于整个应用程序的架构设计。

此外， 所有模式可以根据其意图或目的来分类。 本书覆盖了三种主要的模式类别：

• 创建型模式提供创建对象的机制， 增加已有代码的灵活性和可复用性。
• 结构型模式介绍如何将对象和类组装成较大的结构， 并同时保持结构的灵活和高效。
• 行为模式负责对象间的高效沟通和职责委派。

设计模式分类概览

创建型模式

• 这类模式提供创建对象的机制， 能够提升已有代码的灵活性和可复用性。

结构型模式

• 这类模式介绍如何将对象和类组装成较大的结构， 并同时保持结构的灵活和高效

行为模式

• 这类模式负责对象间的高效沟通和职责委派。

单例

• 单例模式是一种创建型设计模式， 让你能够保证一个类只有一个实例， 并提供一个访问该实例的全局节点

问题

单例模式同时解决了两个问题， 所以违反了单一职责原则：

1. 保证一个类只有一个实例。 为什么会有人想要控制一个类所拥有的实例数量？ 最常见的原因是控制某些共享资源 （例如数据库或文件） 的访问权限。

   它的运作方式是这样的： 如果你创建了一个对象， 同时过一会儿后你决定再创建一个新对象， 此时你会获得之前已创建的对象， 而不是一个新对象。

   注意， 普通构造函数无法实现上述行为， 因为构造函数的设计决定了它必须总是返回一个新对象。

客户端甚至可能没有意识到它们一直都在使用同一个对象。

2. 为该实例提供一个全局访问节点。 还记得你 （好吧， 其实是我自己） 用过的那些存储重要对象的全局变量吗？ 它们在使用上十分方便， 但同时也非常不安全， 因为任何代码都有可能覆盖掉那些变量的内容， 从而引发程序崩溃。

   和全局变量一样， 单例模式也允许在程序的任何地方访问特定对象。 但是它可以保护该实例不被其他代码覆盖。

   还有一点： 你不会希望解决同一个问题的代码分散在程序各处的。 因此更好的方式是将其放在同一个类中， 特别是当其他代码已经依赖这个类时更应该如此。

3. 如今， 单例模式已经变得非常流行， 以至于人们会将只解决上文描述中任意一个问题的东西称为单例

解决方案

所有单例的实现都包含以下两个相同的步骤：

• 将默认构造函数设为私有， 防止其他对象使用单例类的 new运算符。
• 新建一个静态构建方法作为构造函数。 该函数会 “偷偷” 调用私有构造函数来创建对象， 并将其保存在一个静态成员变量中。 此后所有对于该函数的调用都将返回这一缓存对象。

如果你的代码能够访问单例类， 那它就能调用单例类的静态方法。 无论何时调用该方法， 它总是会返回相同的对象。

真实世界类比

政府是单例模式的一个很好的示例。 一个国家只有一个官方政府。 不管组成政府的每个人的身份是什么， “某政府” 这一称谓总是鉴别那些掌权者的全局访问节点。

单例模式结构

单例 （Singleton） 类声明了一个名为 get­Instance获取实例的静态方法来返回其所属类的一个相同实例。

单例的构造函数必须对客户端 （Client） 代码隐藏。 调用 获取实例方法必须是获取单例对象的唯一方式。

伪代码

在本例中， 数据库连接类即是一个单例。 该类不提供公有构造函数， 因此获取该对象的唯一方式是调用 获取实例方法。 该方法将缓存首次生成的对象， 并为所有后续调用返回该对象。

// 数据库类会对`getInstance（获取实例）`方法进行定义以让客户端在程序各处
// 都能访问相同的数据库连接实例。
class Database is
    // 保存单例实例的成员变量必须被声明为静态类型。
    private static field instance: Database

    // 单例的构造函数必须永远是私有类型，以防止使用`new`运算符直接调用构
    // 造方法。
    private constructor Database() is
        // 部分初始化代码（例如到数据库服务器的实际连接）。
        // ……

    // 用于控制对单例实例的访问权限的静态方法。
    public static method getInstance() is
        if (Database.instance == null) then
            acquireThreadLock() and then
                // 确保在该线程等待解锁时，其他线程没有初始化该实例。
                if (Database.instance == null) then
                    Database.instance = new Database()
        return Database.instance

    // 最后，任何单例都必须定义一些可在其实例上执行的业务逻辑。
    public method query(sql) is
        // 比如应用的所有数据库查询请求都需要通过该方法进行。因此，你可以
        // 在这里添加限流或缓冲逻辑。
        // ……

class Application is
    method main() is
        Database foo = Database.getInstance()
        foo.query("SELECT ……")
        // ……
        Database bar = Database.getInstance()
        bar.query("SELECT ……")
        // 变量 `bar` 和 `foo` 中将包含同一个对象。

单例模式适合应用场景

• 如果程序中的某个类对于所有客户端只有一个可用的实例， 可以使用单例模式。

• 单例模式禁止通过除特殊构建方法以外的任何方式来创建自身类的对象。 该方法可以创建一个新对象， 但如果该对象已经被创建， 则返回已有的对象。

• 如果你需要更加严格地控制全局变量， 可以使用单例模式。

• 单例模式与全局变量不同， 它保证类只存在一个实例。 除了单例类自己以外， 无法通过任何方式替换缓存的实例。

  请注意， 你可以随时调整限制并设定生成单例实例的数量， 只需修改 获取实例方法， 即 getInstance 中的代码即可实现。

实现方式

• 在类中添加一个私有静态成员变量用于保存单例实例。
• 声明一个公有静态构建方法用于获取单例实例。
• 在静态方法中实现"延迟初始化"。 该方法会在首次被调用时创建一个新对象， 并将其存储在静态成员变量中。 此后该方法每次被调用时都返回该实例。
• 将类的构造函数设为私有。 类的静态方法仍能调用构造函数， 但是其他对象不能调用。
• 检查客户端代码， 将对单例的构造函数的调用替换为对其静态构建方法的调用。

单例模式优缺点

优点	缺点
你可以保证一个类只有一个实例。	违反了单一职责原则。 该模式同时解决了两个问题。
你获得了一个指向该实例的全局访问节点。	单例模式可能掩盖不良设计， 比如程序各组件之间相互了解过多等。
仅在首次请求单例对象时对其进行初始化。	该模式在多线程环境下需要进行特殊处理， 避免多个线程多次创建单例对象。
	单例的客户端代码单元测试可能会比较困难， 因为许多测试框架以基于继承的方式创建模拟对象。 由于单例类的构造函数是私有的， 而且绝大部分语言无法重写静态方法， 所以你需要想出仔细考虑模拟单例的方法。 要么干脆不编写测试代码， 或者不使用单例模式。

与其他模式的关系

• 外观模式类通常可以转换为单例模式类， 因为在大部分情况下一个外观对象就足够了。
• 如果你能将对象的所有共享状态简化为一个享元对象， 那么享元模式就和单例类似了。 但这两个模式有两个根本性的不同。
  1. 只会有一个单例实体， 但是享元类可以有多个实体， 各实体的内在状态也可以不同。
  2. 单例对象可以是可变的。 享元对象是不可变的。
• 抽象工厂模式、 生成器模式和原型模式都可以用单例来实现

Python单例代码示例

• 基础示例

  class SingletonMeta(type):
      """
      The Singleton class can be implemented in different ways in Python. Some
      possible methods include: base class, decorator, metaclass. We will use the
      metaclass because it is best suited for this purpose.
      """
  
      _instances = {}
  
      def __call__(cls, *args, **kwargs):
          """
          Possible changes to the value of the `__init__` argument do not affect
          the returned instance.
          """
          if cls not in cls._instances:
              instance = super().__call__(*args, **kwargs)
              cls._instances[cls] = instance
          return cls._instances[cls]
  
  
  class Singleton(metaclass=SingletonMeta):
      def some_business_logic(self):
          """
          Finally, any singleton should define some business logic, which can be
          executed on its instance.
          """
  
          # ...
  
  
  if __name__ == "__main__":
      # The client code.
  
      s1 = Singleton()
      s2 = Singleton()
  
      if id(s1) == id(s2):
          print("Singleton works, both variables contain the same instance.")
      else:
          print("Singleton failed, variables contain different instances.")
  

• 线程安全示例

  from threading import Lock, Thread
  
  
  class SingletonMeta(type):
      """
      This is a thread-safe implementation of Singleton.
      """
  
      _instances = {}
  
      _lock: Lock = Lock()
      """
      We now have a lock object that will be used to synchronize threads during
      first access to the Singleton.
      """
  
      def __call__(cls, *args, **kwargs):
          """
          Possible changes to the value of the `__init__` argument do not affect
          the returned instance.
          """
          # Now, imagine that the program has just been launched. Since there's no
          # Singleton instance yet, multiple threads can simultaneously pass the
          # previous conditional and reach this point almost at the same time. The
          # first of them will acquire lock and will proceed further, while the
          # rest will wait here.
          with cls._lock:
              # The first thread to acquire the lock, reaches this conditional,
              # goes inside and creates the Singleton instance. Once it leaves the
              # lock block, a thread that might have been waiting for the lock
              # release may then enter this section. But since the Singleton field
              # is already initialized, the thread won't create a new object.
              if cls not in cls._instances:
                  instance = super().__call__(*args, **kwargs)
                  cls._instances[cls] = instance
          return cls._instances[cls]
  
  
  class Singleton(metaclass=SingletonMeta):
      value: str = None
      """
      We'll use this property to prove that our Singleton really works.
      """
  
      def __init__(self, value: str) -> None:
          self.value = value
  
      def some_business_logic(self):
          """
          Finally, any singleton should define some business logic, which can be
          executed on its instance.
          """
  
  
  def test_singleton(value: str) -> None:
      singleton = Singleton(value)
      print(singleton.value)
  
  
  if __name__ == "__main__":
      # The client code.
  
      print("If you see the same value, then singleton was reused (yay!)\n"
            "If you see different values, "
            "then 2 singletons were created (booo!!)\n\n"
            "RESULT:\n")
  
      process1 = Thread(target=test_singleton, args=("FOO",))
      process2 = Thread(target=test_singleton, args=("BAR",))
      process1.start()
      process2.start()
  

  电子版(完整版)下载地址: https://www.aliyundrive.com/s/uxyLrfbZGp8