设计模式--整体认识与工厂家族

ゝ一世哀愁。 2022-08-06 00:26 188阅读 0赞

学习任何一门技术首先都会想它是用来干嘛的，其次再想应该怎么学，最后思考学会了怎么用？第一遍本着整体把握的心态进行设计模式的钻研，却发觉各种模式都是及其相似的，不停下来总结一番，留在脑子里的任然是一篇混沌！于是放慢步伐，对比总结：

## 【为什么学习设计模式】 ##

官方这样描述设计模式：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。（摘自《百度百科》）

可以理解为我们的编码是有章可循的，本着对代码可复用，易维护，可扩展，灵活性高的高效思想，前人为我们总结了一套编码设计模板，并可以通过形象的图形和语言表示出来。主要采用的设计思想为抽象，封装，继承，多态

![20141207183556014][]

## 【类VS抽象类VS接口】 ##

学习设计模式不得不先简单学习一下抽象和接口的概念：

<table> 
 <tbody> 
 <tr> 
 <td> &nbsp; </td> 
 <td> 声明 </td> 
 <td> 实例化 </td> 
 <td> 用途 </td> 
 <td> 数据成员 </td> 
 <td> 成员方法 </td> 
 <td> 抽象程度 </td> 
 <td> 实现 </td> 
 <td> 设计思想 </td> 
 <td> 举例 </td> 
 </tr> 
 <tr> 
 <td> 类 </td> 
 <td> Class </td> 
 <td> 能 </td> 
 <td> 实例化对象 </td> 
 <td> 普通数据成员 </td> 
 <td> 一般方法，不能为抽象方法 </td> 
 <td> 对象的抽象 </td> 
 <td> &nbsp; </td> 
 <td> &nbsp; </td> 
 <td> 三角形 </td> 
 </tr> 
 <tr> 
 <td> 抽象类 </td> 
 <td> Abstract class </td> 
 <td> 不能 </td> 
 <td> 作为基类（单继承） </td> 
 <td> 普通数据成员 </td> 
 <td> 一般方法，抽象方法（必须被子类重写） </td> 
 <td> 类的抽象 </td> 
 <td> 可部分实现 </td> 
 <td> 子类—&gt;父类 （子类泛化出父类，然后继承父类）--自下而上 </td> 
 <td> 形状 </td> 
 </tr> 
 <tr> 
 <td> 接口 </td> 
 <td> Intreface </td> 
 <td> 不能 </td> 
 <td> 多重继承行为跨越不同对象 </td> 
 <td> 静态下不能修改数据成员 </td> 
 <td> 只能为抽象方法 </td> 
 <td> 行为的抽象（特定功能集合） </td> 
 <td> 所有成员 </td> 
 <td> 不知子类存在，预先定义（自上而下） </td> 
 <td> 绘制图形 </td> 
 </tr> 
 </tbody> 
</table>

简单理解：抽象类就是属性和方法不完整的类，不可以实例化；为继承提供统一的机制。接口是实现多继承时对行为的抽象，可将用法不同的类连接在一起，实现多继承！

举例：

abstract class shape   //抽象类
        { 
            private double area;
            private double primiter;
    
            public void print(shape p)   //可以有一般方法，可以有抽象方法
            {
                Console.WriteLine("绘制形状"+p);
            }
            public abstract void draw();
        }
    
        interface DrawShape  //接口
        {
            public abstract void draw();//必须为抽象方法
        }
    
        class Circle     //一般类
        {
            private double area;
            private double primiter;
            private double radius;
    
            public void draw()
            {
                Console.WriteLine("绘制的三角形");//必须为一般方法
            }

## 【简单工厂模式VS工厂模式】 ##

简单工厂模式与工厂模式都是非常常见的设计模式，但是设计模式的易混淆性迫使我们需要不断应用对比使用才能不断领悟其中的奥妙。

![20141207201534515][]                                                                   ![20141207202221418][]

随着学习的进行，头脑里不断积累起了问题，也只能肤浅的理解一下：

1.为什么要使用简单工厂模式？使用它有什么好处，不用会怎样？

通过对书中实例的学习，从加减乘除类泛化出操作类，某一个具体的运算出现问题后直接修改该类就可以了，其他的类不会对外开放，这样保证了代码保密性，符合开放--封闭原则，可扩展，不准许修改！

想想是有道理的，如果一个项目的代码过大，所有的方法类都集中在一起，一定会造成错误寻找困难的情况，这时具体的操作类都分出来以后，可以很快找到问题根源！充分表现出易维护，灵活性高的编码原则！

简单工程类就负责选择具体哪一个操作类，就像一个工厂一样提供加工的车间！

2.简单工厂模式与工厂模式的区别！

通过上面两幅图可以比较出，简单工厂模式只是抽象出一个基类可以提供具体“加工工具”，简单工厂类通过建立一个车间选择具体的方法！当程序扩大了，需要的机器（方法类）  ，原料（数据成员）和车间（工厂类）势必要增加！才能更加高效的“生产”！

这时大的车间就要考虑分出几个针对不同操作的小车间管理（依赖关系）不同机器（方法类）来达到生产目的。但大车间并不是闲置不用，这时就起到“沟通”作用！毕竟原料从外来运进时不会直接进入小车间，中间必须经过大车间，然后通过大车间来具体分配。这时大车间就起到一个接口（仓库）的作用！

3. 如何理解具体生产过程（代码编写）

任何代码的执行都必须从客户端开始着手，任何类都是从构造函数开始着手，抓住这两个特点对理解代码和编程都有很大的帮助。

对于简单工厂模式（从客户端理解）：

1）实例化操作类。（去购选几套机器）  例如：Operater opra；

2）通过调用简单工厂实例化具体操作类。（选择具体机器） 例如：Opra=new factory.CreateOperater("+");

3）初始化数据成员。（送进原料）opra.numberA=1;

4）返回数据结果。（产品输出）opra.getResult();

对于工厂模式（从客户端理解）：

1）用工厂接口实例化具体子工厂。（选择加工子工厂）IOperaterFactory factory=new AddFactroy();

2）操作接口通过工厂几口调用具体方法。(选择机器)    IOperater opra=new factory.CreateAdd();

3）送进数据

4）加工操作后输出

##   【总结】 ##

感觉但从抽象的角度理解设计模式是远远不够的，还必须结合代码，多问几个为什么，就像什么时候用接口，什么时候用抽象类；有时候单从一个例子并不能得到答案，容易养成以偏概全的陋习！书上的例子很少从一个大的项目去出发，而是简简单单的例子本身出发，容易理解的同时也应该考虑：如果换成一个过百行甚至过千行的例子的话，还会是这样么？如果不是，会有那些问题？这些问题在本书的其他内容中是否有更好的解决方法？

老师常说“**不谋万事者不足谋一域**”，可能有些沾边吧！学习，生活，还需要从日常抓起！

[20141207183556014]: /images/20220806/87718c5164b547e3a464b2820d38d103.png
[20141207201534515]: https://img-blog.csdn.net/20141207201534515
[20141207202221418]: /images/20220806/d346974275df43c8953b6b5b4fd7fb7a.png