案例分析:设计模式与代码的结构特性——高级软件工程课第六次作业

  此次作业,我选择以与“工厂”相关的三个设计模式,即简单工厂模式、工厂方法模式和抽象工厂模式为案例,进行分析。所有代码通过一个单独的C++文件来展现。

1.简单工厂模式

   简单工厂模式(Simple Factory Pattern)属于类的创新型模式,又叫静态工厂方法模式(Static FactoryMethod Pattern),是通过专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。事实上,它并不属于23种设计模式。

简而言之,简单工厂模式就是就是有一个专门生产某个产品的类。

  简单工厂模式的代码案例如下:

const int adidas = 1;
const int nike = 2;
//shirt抽象类
class Shirt
{
public:
    virtual void Show() = 0;
};

//adidas牌shirt 
class AdiShirt : public Shirt
{
public:
    void Show() { cout << "AdiShirt" << endl; }
};

//Nike牌shirt
class NikeShirt : public Shirt
{
public:
    void Show() { cout << "NikeShirt" << endl; }
};

//唯一的工厂,可以生产两种品牌的shirt
class Factory
{
public:
    Shirt* CreateShirt(int brand)
    {
        if (brand == adidas) //工厂内部判断 
            return new AdiShirt(); //生产adidas
        else if (brand == nike)
            return new NikeShirt(); //生产nike 
        else
            return NULL;
    }
};

  分析封装、继承和多态:

       

   AdiShirt和NikeShirt都继承了抽象基类Shirt,并覆盖了show方法,实现了多态。Factory类的CreateShirt方法可根据输入的brand参数来确定生产Adidas牌shirt或是Nike牌Shirt

   带来的好处:这个简单工厂利用了面向对象语言中“继承”这一特性,将决定工厂的生产什么产品的决定权直接交到了客户手中,可以根据客户自己的需求,得到他们想要的最终的结果。

2.工厂方法模式

  简单工厂模式有一个问题就是,类的创建依赖工厂类,也就是说,如果想要拓展程序,必须对工厂类进行修改。这就违反了开放封闭原则:软件实体(类、模块、函数)可以扩展,但是不可修改。假如增加其他品牌的shirt,工厂类需要修改,如何解决?

工厂方法模式在此时应运而生,创建一个工厂接口和创建多个工厂实现类,让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。这样一旦需要增加新的功能,直接增加新的工厂类就可以了,不需要修改之前的代码。

  工厂方法模式的代码案例如下:

  

const int adidas = 1;
const int nike = 2;
//shirt抽象类
class Shirt
{
public:
    virtual void Show() = 0;
};

//adidas牌shirt 
class AdiShirt : public Shirt
{
public:
    void Show() { cout << "AdiShirt" << endl; }
};

//Nike牌shirt
class NikeShirt : public Shirt
{
public:
    void Show() { cout << "NikeShirt" << endl; }
};

//工厂的抽象基类
class Factory
{
public:
    virtual Shirt* CreateShirt(int brand) = 0;
};

//专门生产adidas的工厂
class AdiFactory:public Factory
{
public:
    virtual Shirt* CreateShirt(int brand) {
        return new AdiShirt();
    }
}; 

//专门生产Nike的工厂
class NikeFactory:public Factory 
{
public:
    virtual Shirt* CreateShirt(int brand) {
        return new NikeShirt();
    }
};

  分析封装、继承和多态:

      

  Shirt、AdiShirt和NikeShirt类和简单工厂模式中保持一致,Factory抽象成抽象基类,且分别派生出了AdiFactory和NikeFactory。CreateShirt(int brand)为虚函数,且在两个子类中得到覆盖,即实现了多态。这种模式下,若需要扩展,只需添加新的工厂子类

并且继承Factory这一抽象基类即可。

  带来的好处:克服了简单工厂违背开放-封闭原则的缺点,又保留了封装对象创建过程的优点,降低客户端和工厂的耦合性,“工厂方法模式”是“简单工厂模式”的进一步抽象和推广。

3.抽象工厂模式  

  不仅可以生产Shirt,还能生产Pants。现在简单工厂模式和工厂方法模式都无法更好地完成工作。抽象工厂模式应运而生。它的定义为提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。具体为,存在两个工厂(该案例中)一个专门用来生产Adidas品牌的Shirt和Pants,而另一个工厂专门用来生产Nike的Shirt和Pants。
  工厂方法模式的代码案例如下:

  

const int adidas = 1;
const int nike = 2;
//shirt抽象类
class Shirt
{
public:
    virtual void Show() = 0;
};

//adidas牌shirt 
class AdiShirt : public Shirt
{
public:
    void Show() { cout << "AdiShirt" << endl; }
};

//Nike牌shirt
class NikeShirt : public Shirt
{
public:
    void Show() { cout << "NikeShirt" << endl; }
};

//Pants抽象类
class Pants
{
public:
    virtual void Show() = 0;
};

//adidas牌pants
class AdiPants : public Pants
{
public:
    void Show() { cout << "AdiPants" << endl; }
};

//Nike牌pants
class NikePants : public Pants
{
public:
    void Show() { cout << "NikePants" << endl; }
};

//工厂的抽象基类
class Factory
{
public:
    virtual Shirt* CreateShirt(int brand) = 0;
    virtual Pants* CreatePants(int brand) = 0;
};

//专门生产adidas的工厂
class AdiFactory :public Factory
{
public:
    virtual Shirt* CreateShirt(int brand) {
        return new AdiShirt();
    }
    virtual Pants* CreatePants(int brand) {
        return new AdiPants();
    }
}; 

//专门生产nike的工厂
class NikeFactory :public Factory
{
public:
    virtual Shirt* CreateShirt(int brand) {
        return new NikeShirt();
    }
    virtual Pants* CreatePants(int brand) {
        return new NikePants();
    }
};

  分析封装、继承和多态:

      

    

  相比上面两种模式,抽象工厂模式又定义了Pants基类和AdiPants、NikePants两个子类。此外对于抽象基类Factory,新增了虚函数CreatePants,并且新派生出了子类NikeFactory。在两个工厂子类——AdiFactory和NikeFactory中继承并覆盖了虚函数

CreateShirt和CreatePants,实现了多态。每个工厂子类只负责生产自己品牌的服装——shirt或pants

  带来的好处:抽象工厂模式较好的实现了“开放-封闭”原则,是三个模式中较为抽象,并具一般性的模式。这样模块更加清晰,每个部分都各司其职,分工明确,可维护性更好。

猜你喜欢

转载自www.cnblogs.com/hhssqq9999/p/11991723.html
今日推荐