zhanghw的博客

一、说明 代理模式：为其它对象提供一种代理以控制这个对象的访问。在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介作用。 优点： 职责清晰。真实的角色只负责实现实际的业务逻辑，不用关心其它非本职责的事务，通过后期的代理完成具体的任务。这样代码会简洁清晰。 代理对象可以在客户端和目标对象之间起到中介的作用，这样就保护了目标对象。 扩展性好。 二、代码 #ifndef PROXY_H #define PROXY_H #include <QString&g

一、说明 享元模式：运用共享技术有效地支持大量细粒度的对象。在有大量对象时，把其中共同的部分抽象出来，如果有相同的业务请求，直接返回内存中已有的对象，避免重新创建。 以下情况可以考虑使用享元模式： 系统中有大量的对象，这些对象消耗大量的内存，且这些对象的状态可以被外部化。 对于享元模式，需要将对象的信息分为两个部分：内部状态和外部状态。内部状态是指被共享出来的信息，储存在享元对象内部且不随环境变化而改变；外部状态是不可以共享的，它随环境改变而改变，是由客户端控制的。 二、代码 #ifndef SHARE_H

一、说明 桥接模式：将抽象部分与实现部分分离，使它们都可以独立变换。 以下情形考虑使用桥接模式： 当一个对象有多个变化因素的时候，考虑依赖于抽象的实现，而不是具体的实现。 当多个变化因素在多个对象间共享时，考虑将这部分变化的部分抽象出来再聚合/合成进来。 当一个对象的多个变化因素可以动态变化的时候。 优点： 将实现抽离出来，再实现抽象，使得对象的具体实现依赖于抽象，满足了依赖倒转原则。更好的可扩展性。 可动态的切换实现。桥接模式实现了抽象和实现的分离，在实现桥接模式时，就可以实现动态的选择具体的实现。 二、

一、说明 装饰模式：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。有时我们希望给某个对象而不是整个类添加一些功能。比如有一个手机，允许你为手机添加特性，比如增加挂件、屏幕贴膜等。一种灵活的设计方式是，将手机嵌入到另一对象中，由这个对象完成特性的添加，我们称这个嵌入的对象为装饰。这个装饰与它所装饰的组件接口一致，因此它对使用该组件的客户透明。 二、代码 #ifndef DECO_H #define DECO_H #include <QDebug> #includ

一、说明 备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原来保存的状态。 二、代码 #ifndef BEIWANGLU_H #define BEIWANGLU_H #include <QWidget> #include <QDebug> typedef struct{ int grade;//级别 QString arm;//武器 QString corps;//兵团 }GameValue;

一、说明 中介者模式：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之前的交互。 如果对象与对象之前存在大量的关联关系，若一个对象改变，常常需要跟踪与之关联的对象，并做出相应的处理，这样势必会造成系统变得复杂，遇到这种情形可以考虑使用中介者模式。当多个对象存在关联关系时，为它们设计一个中介对象，当一个对象改变时，只需要通知它的中介对象，再由它的中介对象通知每个与它相关的对象。 二、代码 #ifndef ZHONGJIE_H #define

一、说明 职责链模式： 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之前的耦合关系，将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。 职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无需关心请求的处理细节和请求的传递，所有职责链将请求的发送者和请求的处理者解耦了。 二、代码 #ifndef FORM_H #define FORM_H enum Level{ level_one, level_two, level_three };

一、说明 建造者模式：将复杂对象的构建和其表示分离，使得相同的构建过程可以产生不同的表示。 以下情形可以考虑使用建造者模式： 对象的创建复杂，但是其各个部分的子对象创建算法一定。 需求变化大，构造复杂对象的子对象经常变化，但将其组合在一起的算法相对稳定。 建造者模式的优点： 将对象的创建和表示分离，客户端不需要了解具体的构建细节。 增加新的产品对象时，只需要增加其具体的建造类即可，不需要修改原来的代码，扩展方便。 产品之间差异性大，内部变化较大、较复杂时不建议使用建造者模式。 二、代码 #ifndef BU

一、说明 模式策略是一种定义一系列算法的方法，从概念上看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。实践中只要在分析过程出现需要在不同时间应用不同的业务规则，就可以考虑使用策略模式。 二、代码 #ifndef STRATEGY_H #define STRATEGY_H //抽象算法类 class strategy { public: virtual ~strategy(); virtual void Algo

一、说明 观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都要得到通知并自动更新。 观察者模式从根本上讲必须包含两个角色：观察者和被观察对象。 被观察对象自身应该包含一个容器来存放观察者对象，当被观察者自身发生改变时通知容器内所有的观察者对象自动更新。 观察者对象可以注册到被观察者的中，完成注册后可以检测被观察者的变化，接收被观察者的通知。当然观察者也可以被注销掉，停止对被观察者的监控。 二、代码 #ifndef FORM_H #define FORM_H #i

一、说明 定义一个创建对象的接口，其子类去具体现实这个接口以完成具体的创建工作。如果需要增加新的产品类，只需要扩展一个相应的工厂类即可。 缺点：产品类数据较多时，需要实现大量的工厂类，这无疑增加了代码量。 二、代码 #ifndef WIDGET_H #define WIDGET_H #include <QString> class product { virtual const QString& type()=0; }; class shoe_product:public pr

一、说明 在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。工厂模式作为一种创建模式，一般在创建复杂对象时，考虑使用；在创建简单对象时，建议直接new完成一个实例对象的创建。 主要特点是需要在工厂类中做判断，从而创造相应的产品，当增加新产品时，需要修改工厂类。使用简单工厂模式，我们只需要知道具体的产品型号就可以创建一个产品。 缺点：工厂类集中了所有产品类的创建逻辑，如果产品量较大，会使得工厂类变的非常臃肿。 二、代码 #ifndef WIDGET_H #

一、代码 #ifndef INSTANCE_H #define INSTANCE_H #include <QObject> #include <QMutex> #include <QMutexLocker> class instance : public QObject { Q_OBJECT public: explicit instance...