标签：子类 处理 ref main log 带来 images 客户 new
在面向对象系统设计中经常可以遇到以下的两类问题：
1）为了提高内聚和松耦合，我们经常会抽象出一些类的公共接口以形成抽象基类或者接口。这样我们可以通过声明一个指向基类的指针来指向实际的子类实现，达到了多态的目的。这里很容易出现的一个问题： n 多的子类继承自抽象基类，我们不得不在每次要用到子类的地方就编写诸如 new ×××;的代码。这里带来两个问题
①客户程序员必须知道实际子类的名称（当系统复杂后，命名将是一个很不好处理的问题，为了处理可能的名字冲突，有的命名可能并不是具有很好的可读性和可记忆性，就姑且不论不同
程序员千奇百怪的个人偏好了）
②程序的扩展性和维护变得越来越困难。
2）还有一种情况就是在父类中并不知道具体要实例化哪一个具体的子类。
以上两个问题也就引出了Factory模式的两个最重要的功能：
1）定义创建对象的接口，封装了对象的创建；
2）使得具体化类的工作延迟到了子类中。
如图，FactoryA专心负责生产ProductA，FactoryB专心负责生产ProductB，FactoryA和FactoryB之间没有关系；如果到了后期，如果需要生产ProductC时，我们则可以创建一个FactoryC工厂类，该类专心负责生产ProductC类产品。由于FactoryA、FactoryB和FactoryC之间没有关系，当加入FactoryC加入时，对FactoryA和FactoryB的工作没有产生任何影响，那么对代码进行测试时，只需要单独对FactoryC和ProductC进行单元测试，而FactoryA和FactoryB则不用进行测试，则可省去大量无趣无味的测试工作。
工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。
由于使用设计模式是在详细设计时，就需要进行定夺的，所以，需要权衡多方面的因素，而不能为了使用设计模式而使用设计模式。
#include <iostream> using namespace std; class Product { public: virtual void Show() = 0; }; class ProductA : public Product { public: void Show() { cout<< "I‘m ProductA"<<endl; } }; class ProductB : public Product { public: void Show() { cout<< "I‘m ProductB"<<endl; } }; class Factory { public: virtual Product *CreateProduct() = 0; }; class FactoryA : public Factory { public: Product *CreateProduct() { return new ProductA (); } }; class FactoryB : public Factory { public: Product *CreateProduct() { return new ProductB (); } }; int main(int argc , char *argv []) { Factory *factoryA = new FactoryA (); Product *productA = factoryA->CreateProduct(); productA->Show(); Factory *factoryB = new FactoryB (); Product *productB = factoryB->CreateProduct(); productB->Show(); if (factoryA != NULL) { delete factoryA; factoryA = NULL; } if (productA != NULL) { delete productA; productA = NULL; } if (factoryB != NULL) { delete factoryB; factoryB = NULL; } if (productB != NULL) { delete productB; productB = NULL; } return 0; }
标签：子类 处理 ref main log 带来 images 客户 new
原文地址：http://www.cnblogs.com/wujing-hubei/p/6285774.html
