设计模式-组件协作

前言

组件协作模式 ：现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。 典型模式：

• Template Method 模板方法
• Observer/Event 观察者模式
• Strategy 策略模式

1 Template Method

1.1 模式介绍

动机：在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。 比如：在Linux上构建一个Tcp服务器，不可避免的操作是：创建套接字、绑定ip和port、监视端口、获取连接、处理请求、断开连接 在这个过程中，通常只有处理请求的操作是变化的，而整体框架是不变的，为了将变化框在笼子里，就有了模板方法模式 模式定义：

定义一个操作中的算法的骨架 (稳定)，而将一些步骤延迟(变化)到子类中。 Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(override 重写)该算法的某些特定步骤。

——《设计模式》 GoF

1.2 代码案例

1.2.1 问题代码

//程序库开发人员 class Library{ public: void Step1(){ //… } void Step3(){ //… } void Step5(){ //… } }; //应用程序开发人员 class Application{ public: bool Step2(){ //… } void Step4(){ //… } }; int main() { Library lib(); Application app(); lib.Step1(); if (app.Step2()){ lib.Step3(); } for (int i = 0; i < 4; i++){ app.Step4(); } lib.Step5(); } 这个代码的问题在于，很多重复工作，程序整体流程是定的，只是某几步不同而已

1.2.2 重构代码

//程序库开发人员 class Library { public: //稳定 template method void Run() { Step1(); if (Step2()) { //支持变化 ==> 虚函数的多态调用 Step3(); } for (int i = 0; i < 4; i++) { Step4(); //支持变化 ==> 虚函数的多态调用 } Step5(); } virtual ~Library() { } protected: void Step1() { //稳定 //….. } void Step3() {//稳定 //….. } void Step5() { //稳定 //….. } virtual bool Step2() = 0;//变化 virtual void Step4() = 0; //变化 }; //应用程序开发人员 class Application : public Library { protected: virtual bool Step2() { //… 子类重写实现 } virtual void Step4() { //… 子类重写实现 } }; int main() { Library* pLib = new Application(); pLib->Run(); delete pLib; }

1.3 模式类图

1.4 要点总结

• Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。
• 除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你”的反向控制结构是Template Method的典型应用。
• 在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法

2 Strategy

2.1 模式介绍

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化） 。

——《设计模式》 GoF

2.2 代码案例

假设有一个税收计算系统，每个国家有其自己的税收计算方法，那么要实现此系统应该怎么编码呢？

2.2.1 问题代码

enum TaxBase { CN_Tax, US_Tax, DE_Tax, FR_Tax //更改 }; class SalesOrder{ TaxBase tax; public: double CalculateTax(){ //… if (tax == CN_Tax){ //CN*********** } else if (tax == US_Tax){ //US*********** } else if (tax == DE_Tax){ //DE*********** } else if (tax == FR_Tax){ //更改 //… } //…. } }; 此方法是对国家进行判断，每个国家执行对应的代码，这样的代码有什么坏处？ 当国家增多时，就要在后面增加if判断，这样的代码是极其不好的。

2.2.2 重构代码

class TaxStrategy{ public: virtual double Calculate(const Context& context)=0; virtual ~TaxStrategy(){} }; class CNTax : public TaxStrategy{ public: virtual double Calculate(const Context& context){ //*********** } }; class USTax : public TaxStrategy{ public: virtual double Calculate(const Context& context){ //*********** } }; class DETax : public TaxStrategy{ public: virtual double Calculate(const Context& context){ //*********** } }; //扩展 //********************************* class FRTax : public TaxStrategy{ public: virtual double Calculate(const Context& context){ //……… } }; class SalesOrder{ private: TaxStrategy* strategy; public: SalesOrder(StrategyFactory* strategyFactory){ this->strategy = strategyFactory->NewStrategy(); } ~SalesOrder(){ delete this->strategy; } public double CalculateTax(){ //… Context context(); double val = strategy->Calculate(context); //多态调用 //… } }; 重构以后的代码将税收策略与系统进行了解耦，当策略增加时，只需要增加对应的类即可

2.3 模式类图

2.4 要点总结

• Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
• Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
• 如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。

3 Observer/Event

3.1 模式介绍

动机：在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。

定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

——《设计模式》 GoF

3.2 问题引入

假设你有两种类型的对象： aCustomer和 a Store。客户对某个特定品牌的产品非常感兴趣（比如说，它是新款 iPhone），该产品应该很快就会在商店上架。 另一方面，每次有新产品上市时，商店可以向所有客户发送大量电子邮件（可能被视为垃圾邮件）。这可以让一些客户免于无休止地跑到商店。同时，它会让其他对新产品不感兴趣的客户感到不安。 看起来我们遇到了冲突。要么客户浪费时间检查产品库存，要么商店浪费资源通知错误的客户。

3.3 解决方法

具有一些有趣状态的对象通常称为主体，但由于它也会将其状态的变化通知其他对象，因此我们将其称为发布者。所有其他想要跟踪发布者状态变化的对象称为订阅者。 观察者模式建议你为发布者类添加订阅机制，这样单个对象就可以订阅或取消订阅来自该发布者的事件流。别担心！一切并没有听起来那么复杂。实际上，该机制包括

1. 一个用于存储订阅者对象引用列表的数组字段和
2. 几个允许将订阅者添加到该列表和从该列表中删除订阅者的公共方法。 现在，每当发布者发生重要事件时，它都会检查其订阅者并调用其对象上的特定通知方法。 实际应用可能会有几十个不同的订阅者类，它们对跟踪同一发布者类的事件感兴趣。您不会想将发布者与所有这些类耦合在一起。此外，如果您的发布者类应该被其他人使用，您可能甚至事先不知道其中一些。 这就是为什么所有订阅者都实现相同的接口并且发布者仅通过该接口与他们通信至关重要的原因。此接口应声明通知方法以及一组参数，发布者可以使用这些参数随通知传递一些上下文数据。

3.4 模式代码

#include #include

#include class IObserver { public: virtual ~IObserver() {}; virtual void Update(const std::string &message_from_subject) = 0; }; class ISubject { public: virtual ~ISubject() {}; virtual void Attach(IObserver observer) = 0; virtual void Detach(IObserver observer) = 0; virtual void Notify() = 0; }; / * Subject 拥有一些重要的状态，并在状态发生变化时通知观察者。/ class Subject : public ISubject { public: virtual ~Subject() {} /** * 订阅管理方法。/ void Attach(IObserver *observer) override { list_observer_.push_back(observer); } void Detach(IObserver *observer) override { list_observer_.remove(observer); } void Notify() override { std::list::iterator iterator = list_observer_.begin(); while (iterator != list_observer_.end()) { (*iterator)->Update(message_); ++iterator; } } void CreateMessage(std::string message = “Empty”) { this->message_ = message; Notify(); } void SomeBusinessLogic() { this->message_ = “更改消息消息”; Notify(); std::cout « “我即将做一些重要的事情\n”; } private: std::list list_observer_; std::string message_; }; class Observer : public IObserver { public: Observer(Subject &subject) : subject_(subject) { this->subject_.Attach(this); std::cout « “嗨，我是观察员 "” « ++Observer::static_number_ « “".\n”; this->number_ = Observer::static_number_; } virtual ~Observer() {} void Update(const std::string &message_from_subject) override { message_from_subject_ = message_from_subject; PrintInfo(); } void RemoveMeFromTheList() { subject_.Detach(this); std::cout « “观察员 "” « number_ « “" 从列表中删除。\n”; } void PrintInfo() { std::cout « “Observer "” « this->number_ « “": 有新消息可用 –> " « this->message_from_subject_ « “\n”; } private: std::string message_from_subject_; Subject &subject_; static int static_number_; int number_; };

3.5 模式类图

3.6 要点总结

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