设计模式总结（持续更新……）_设计模式在屏幕上绘制圆形、三角形、矩形等各种图形,可以用不同颜色绘制不同-优快云博客

本文深入探讨软件工程中的设计模式，包括创建型模式如简单工厂、单例，结构型模式如适配器、装饰器，及行为型模式如命令、观察者等。解析每种模式的动机、实现方式、优缺点，帮助开发者掌握设计模式精髓。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

动机：将实体和实现脱耦。
实现：实体都继承自一个抽象的实体类，实现都继承自一个抽象的实现类。将实体和实现在抽象层面上关联起来。
例子：用不同颜色绘制不同形状的图形，如圆形、矩形、三角形。这些图形继承自一个抽象的 Shape 类，是实体；用不同颜色进行绘制继承自一个抽象的 Paint 类，是实现。
优点：在实体和实现两个维度上都能方便地进行扩展。
缺点：在程序设计上难度较高，很难区分出实体和实现。
原则：体现了合成利用原则。

动机：将客户与子系统松耦合，向用户隐藏子系统的复杂性，提供客户使用的便捷性，让客户端代码变简单。
实现：一个外观类，一组子系统。外观类与这些子系统关联，作为客户调用这些子系统的接口，客户通过调用外观类来实现子系统中的功能。
原则：体现了迪米特法则（即最少知道原则），违背了开闭原则（当有新的子系统加入时，需要修改外观类，解决方法：在具体外观类的上层再加一个抽象外观类，当有新的子系统加入时，不是修改已有的外观类，而是新增具体外观类）。
使用场景（优点）：
－ 1) 当想为客户提供一个复杂子系统的简单接口时。
－ 2) 当想要提高子系统的独立性和可移植性时：新增的子系统可以单独编译，降低了大规模系统的编译信赖性；对子系统的修改不需要改动客户代码，只需要改动外观类。
－ 3) 适用于层次结构的系统，为每一层提供一个外观类作为接口，降低层与层之间的耦合度。
缺点：违背了开闭原则，解决方法在第 3 点中。
注：外观类通常是个单例类，一个系统可以有多个外观类（多例模式）。另外，客户端也可以不通过外观类直接访问子系统。再另外，“子系统” 不一定是一个类，也可能是共同完成某个任务的多个类。

动机：通过共享技术实现相同或相似对象的重用。
实现：一个享元工厂类，维护一个享元池（map）。用户在想要获得享元对象时，不直接创建享元对象，而是通过享元工厂来 get 享元对象，在 get 时传入一个参数 (此参数为可以共享的 “内部状态” 的某个值) 表示想要获得的享元对象的类型，当享元池中没有此类型的对象时，新建一个放入享元池并返回此对象，当享元池中有此类型的对象时，直接返回。由用户来对返回的对象的那些不可共享的 “外部状态” 的值来进行设置 (即 set 这些属性的值)。
例子：想像这样的一个应用，我想要让屏幕上交替地出现白点和黑点，可以使用享元模式，享元池中就只有白点和黑点两个对象，每次传一个标志位给享元工厂（表示 white 或 black），享元工厂返回给我对应的对象，然后我修改这个对象的 x y 坐标 (外部状态)，再调用它的 draw 方法让它出现。全程只有两个对象，不用每次都创建新的对象。
适用场景（优点）：某些很相似的对象多次重复出现，使用享元模式可以让这些相似的对象只有一份拷贝。
缺点：由于需要设置外部状态，使系统（客户端）逻辑复杂。

动机：客户不想或不能直接调用一个对象，需要用代理来作为中介。
实现：一个真实主题类提供真正的 real_request() 操作；一个代理类，代理类中包含一个真实主题类的成员 read_subject，在代理类的构造函数中创建 read_subject；代理类还包含一个 request() 成员函数，在 request 中调用 read_subject.real_request()，同时也可能有一些它自己的 before_request() 或 after_request() 来对真实操作进行修饰。
几种代理：
－ 1) 远程代理：代理服务器。
－ 2) 虚拟代理：比如浏览器加载的时候，先加载小图，当用户真正点击图片的时候再加载大图，小图就是大图的虚拟代理。写时复制也是一种虚拟代理。
－ 3) 保护代理：在代理中判断调用者的权限实现保护作用，如防火墙代理。
－ 4) 缓冲代理：将调用结果临时存储下来以供其它用户访问。
－ 5) 同步化代理：使几个用户能同时访问一个对象而没有冲突（如假脱机技术 SPOOLing）
－ 6) 智能引用代理（如智能指针）
优点：就是上述的这些啦。
缺点：可能会造成请求的处理速度变慢。