Tiantangbujimo7的博客

解释器模式（Interpreter Pattern） 是一种行为型设计模式，它提供了一个解释语言的方式。该模式用于处理一个特定语言的语法规则，通过一个解释器（通常是一个类或一组类）来解释和执行该语言的语法。解释器模式通常用于实现一个简单的编程语言、脚本语言或表达式求值。// 抽象表达式接口public:// 解释方法，返回计算结果Expression 是所有表达式的抽象接口，声明了 interpret() 方法，该方法将执行表达式的解释（计算）。

访问者模式（Visitor Pattern） 是一种行为型设计模式，它允许你在不修改元素类的前提下，添加新的操作。访问者模式通过将操作封装在访问者对象中，从而使得你可以为不同类型的元素执行不同的操作，而不需要改变元素类的代码。// 访问者接口public:ShapeVisitor 是访问者接口，声明了访问不同元素的方法。每个具体访问者会实现这些方法，针对不同的图形执行不同的操作。// 元素接口public:// 接受访问者。

命令模式（Command Pattern） 是一种行为型设计模式，它将请求封装成一个对象，从而使您可以使用不同的请求、队列、日志请求以及支持撤销操作等功能。命令模式通过将请求（命令）封装成对象，使得客户端可以将请求发送者与请求接收者解耦，从而更灵活地控制操作的执行。// 命令接口public:// 执行命令的接口Command 是命令接口，声明了 execute() 方法，该方法将由具体命令类来实现。

责任链模式（Chain of Responsibility Pattern） 是一种行为型设计模式，它使得多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将多个处理对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。每个对象在处理请求时，可以决定将请求传递给链中的下一个对象。// 处理者接口protected:// 下一个处理者public:// 设置下一个处理者// 处理请求。

迭代器模式（Iterator Pattern） 是一种行为型设计模式，它提供了一种方法，使得可以顺序访问一个集合对象中的元素，而无需暴露集合对象的内部结构。通过迭代器模式，客户端可以通过统一的接口遍历容器中的元素，无论容器的具体实现如何。// 迭代器接口public:// 判断是否还有下一个元素// 获取下一个元素Iterator 是迭代器接口，定义了遍历集合的两个关键方法：hasNext() 和 next()。public:// 创建迭代器。

组合模式（Composite Pattern） 是一种结构型设计模式，它将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式让客户端可以以相同的方式对待单个对象和对象集合。组合模式使得客户可以统一处理树形结构中的单个对象和对象的集合，简化了对象的使用和管理。// 组件接口：部门和员工的共同接口public:// 显示信息IComponent 是所有部门和员工的公共接口，声明了 showInfo() 方法，用于展示信息。

备忘录模式（Memento Pattern） 是一种行为型设计模式，允许在不暴露对象实现细节的情况下，保存和恢复对象的状态。备忘录模式的核心思想是将对象的状态保存到一个外部对象（备忘录）中，这样对象可以随时恢复到先前的状态。通过备忘录模式，可以实现对象状态的回滚，例如撤销操作等。// 备忘录类：用于存储文本编辑器的状态private:// 存储文本状态public:// 获取存储的状态Memento 类是备忘录模式的核心，它封装了文本编辑器的状态。

状态模式（State Pattern） 是一种行为型设计模式，它允许对象在其内部状态改变时改变其行为。也就是说，状态模式通过封装对象的状态，使得对象在不同的状态下表现出不同的行为，状态的切换由状态对象来控制。// 状态接口public:// 定义投票方法VoteState 是状态接口，定义了 vote() 方法，表示在不同状态下的投票行为。

中介者模式（Mediator Pattern） 是一种行为型设计模式，旨在通过引入一个中介者对象来简化类与类之间的交互。在这个模式中，各个对象之间不直接交互，而是通过中介者对象来协调它们之间的通信。这样可以避免多个对象之间直接相互依赖，从而降低了系统的复杂度和耦合度。// 中介者接口public:IChatRoom 是中介者接口，定义了所有同事对象与中介者交互的方式。它有两个主要的方法：sendMessage()：用于发送消息。addUser()：用于添加用户。

适配器模式（Adapter Pattern） 是一种结构型设计模式，它允许将一个类的接口转换成客户端所期望的另一种接口。适配器模式通常用于将已有的类或遗留系统中的接口与新系统或目标接口进行兼容，从而能够在系统中无缝地使用不兼容的类。解耦：客户端与旧接口解耦，客户端通过目标接口与适配器交互，不直接与遗留系统进行交互。复用：适配器模式可以使旧系统或类重用，而不需要修改旧代码。适应性强：代理类可以灵活适应不同的接口需求，尤其在接口不兼容时尤为有用。

外观模式（Facade Pattern） 是一种结构型设计模式，它通过为复杂的子系统提供一个统一的接口，使得子系统的使用更加简化。外观模式通常隐藏了复杂的内部子系统，使得客户端可以通过一个简单的接口与这些子系统进行交互。简化接口：将复杂子系统的接口进行封装，提供统一的简单接口。解耦：客户端不再与子系统的多个组件交互，只与外观类交互，减少了系统之间的耦合。提高可维护性：外观模式通过将子系统的复杂性隐藏在外观类中，使得系统的维护更加容易增加了外观类的复杂性。

单例模式（Singleton Pattern） 是一种创建型设计模式，确保一个类在整个程序生命周期中只能有一个实例，并提供一个全局访问点。方式线程安全实现复杂度适用场景传统懒汉式× 否简单仅限单线程DCLP（双重检查锁定）√ 是复杂C++11 之前的多线程√ 是较复杂需要高性能√ 是简单现代 C++ 推荐局部静态变量√ 是最简单C++11 推荐Singleton模式中的实力构造器可以设置为protected以允许子类派生。

建造者模式（Builder Pattern）是一种创建型设计模式，旨在将复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示。该模式的核心思想是通过一步步地构建一个复杂的对象，每个步骤独立且可扩展，并且最终的产品（对象）可以通过不同的构建步骤得到不同的结果。建造者模式通过分离复杂对象的构建过程和对象的表示，使得构建过程更加灵活，支持多种对象表示方式。在实际开发中，当对象的构建过程繁琐且有多个可选的组成部分时，建造者模式是一种非常有效的设计模式。

使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。什么时候使用原型，什么时候使用工厂最大的区分点就在于：用工厂方法创建对象是不是非常简单的几个步骤就可以把这个对象创建出来，还是说需要考虑对象很复杂的中间状态，然后又很希望保留这个中间状态，如果是后者的话就用原型。Prototype模式同样用于隔离类对象的使用者和具体类型(易变类)之间的耦合关系，它同样要求这些“易变类”拥有稳定的接口。

抽象工厂与工厂方法极其类似，都是绕开new的，但是有些许不同。

这里可以看到 我们在 MemoryStream* stream;都是某个类型的子类的时候，之间声明成某个类型。，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。在软件组件设计中，如果责任划分不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。这里可以看到 加密的操作都是相同的，但是读取的方式是不同的。那么我们发现，可以合并这个类。

通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导致软件的脆弱。

Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

使用面向对象的抽象，Observer 模式使得我们可以独立地改变目标与观察者,从而使二者之间的依赖关系达到松耦合目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知，目标对象对此一无所知。Observer 模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

定义一系列算法，把它们一个个封装起来，并且使他们可互相替换（变化）。该模式使算法可独立于使用它的客户程序（稳定）而变化（拓展，子类化Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。Strategy 模式提供了用条件判断语句之外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要 Strategy 模式。

在这里 什么时候、什么地点应用设计模式，比理解设计模式结构代码本身更加重要。现在软件设计的特征是 “需求的频繁变化”。

设计模式

对 MainForm 的设计，删除 lineVector 和 rectVector 只需要设计 vector 的 Shape 就可以应对所有形状。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。人们面对复杂性有一个常见的做法：既分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。首先设置一个 Shape（形状）的父类,设置一个纯虚函数Draw，和一个虚析构函数。在这里只有虚析构函数子类通过多态释放的时候，子类的虚析构函数才会被正确的调用到。