你为什么总是学不会设计模式？

1. 前言

设计模式——最熟悉的陌生人。

很多人应该都有这种感受，早就知道设计模式，也能随口说出几种，但是不知道每种是怎么回事。或者说只知道工厂模式等几个常用，简单的。估计那也是靠记忆，而不是真正的理解。

我也有这种亲身体会，在好几年之前就知道设计模式。之前也一直抽时间学，但总是学了就忘。而且学习过程很枯燥，完全是背诵式的记忆那些类图，不是真正的理解，更别提应用了。

 

2. 关于“设计”

设计，就是为了更好的应对变化。没毕业时候不知道软件系统怎么会有变化，但是工作之后慢慢就会发现，变化，那叫一个天马行空。。。

一提到“设计”，大部分人可能会直接想到设计模式，而且是23种设计模式。其实这是错误的。其实学会设计、应用设计，应该分为四个层次：

 

2.1 面向对象 

首先要了解面向对象，什么是面向对象？什么是封装、继承和多态，以及三个特点的表现形式。基础很重要。

要想充分了解面向对象，三个特点，最好还是按部就班的参考一本权威书籍，看看书上说的你是不是真的理解。看看继承和多态的表现形式你是否都知道。

如果没按部就班看过书，就不要以为自己都会了。借用某相声演员一句话：“你以为你以为的就是你以为的？”。。。

 

2.2 抽象与具体

如何更好的解决“变化”问题？答案是“提取抽象、隔离具体”。 

什么是“抽象”？ 抽象就是不变的东西，一个数据表的操作，总会有增删改查，把他们作为接口，这是不变的。

什么是“具体”？ 具体是实际执行的，一个数据表的增删改查，用sqlserver、access还是oracle？可能会有变化。

我们应该依赖于抽象编程，而不是依赖于具体编程。应该把程序中的共性抽象出来，并且把具体实现的部分隔离开来，让他们都依赖于抽象，并且互不影响。这其实就是设计。

只有理解了“抽象”、“具体”、“隔离”这几个词儿，你才能真正理解设计模式。否则就别指望。

 

2.3 SOLID五大原则

系统设计的5大原则，简写分别是S、O、L、I、D。

• S - 类职责单一原则： 即职责划分要清晰，不同职责的不要搅和在一起。每个类应该只有一个让他发生改变的原因。
• O - 开放封闭原则： 对扩展开发，对修改封闭。即如果系统要变化，就去扩展、新增新类，不要修改现有的类。
• L - LISKOV原则： 子类应该能充分覆盖父类，并且让使用者分不出差别。
• I - 接口分离原则：每个接口只管一个功能，不要出现“胖接口”。增加功能时，要加接口，而不是改接口
• D - 依赖倒置原则：具体应该依赖于抽象，而不是抽象一来于具体，即低层要依赖于高层。

对于以上5大原则，此处不详细解释，有兴趣的可以查阅《你必须知道的.net》第二版，里面讲的非常详细。

如果详细分析这5大原则，其实他们都是围绕着“提取抽象、隔离具体”来的。

• S - 类职责单一原则： 隔离
• O - 开放封闭原则： 依赖于抽象，隔离具体
• L - LISKOV原则：抽象
• I - 接口独立原则：隔离
• D - 依赖倒置原则：依赖于抽象

 

2.4 设计模式

最后才是设计模式，设计模式其实是一些工具而已。

是“术”，不是“道”。如果你不明白以上那些“道”，而直接去学“术”，肯定是学一次忘一次。

在看每个设计模式的时候，你都要去向着这个方向去思考：它是不是提取了抽象、分离了具体、依赖于抽象、封装了具体？ 这样一来，你就会明白了。

 

3 例子：工厂模式

工厂模式在设计模式中分三种：简单工厂、工厂方法和抽象工厂，其实这三种对应了不同的抽象程度。 下面简单分析前两种。

3.1 简单工厂：

看上图，很明显是“提取抽象，分离具体”。将数据操作的接口提取出来，交给不同的实现类来实现。

工厂类返回的是IDBHelper接口，即客户端会调用IDBHelper接口，而不需要关心具体实现，这就是“依赖于抽象，而不是依赖于具体”。

还符合“开放封闭原则”，例如现在又要用DB2数据库，那么再加一个实现类就行，无需改其他地方。客户端也不会察觉后台的变化。这就是：对扩展开放，对修改封闭。

 

简单工厂之所以叫“简单”，是因为它的工厂类还依赖于数据操作实现类，这违反了“依赖倒置原则”，那么该怎么办呢？

 

3.2 工厂方法：

上文说了，简单工厂类依赖与数据操作实现类，当前有3个实现类，那么工厂类肯定需要判断，免不了有if else或者swicth case语句，

switch (type)
            {
                case "sqlserver":
                    return new SQLDBHelper();
                case "oracle":
                    return new OracleDBHelper();
                case "access":
                    return new AccessDBHelper();
                default:
                    throw new Exception("type参数错误");
            }

而这些语句，就是设计模式重点要改进的地方。

如何让工厂类不依赖于数据操作实现类？ 答案还是“提取抽象，分离具体实现”。

 

将工厂类的具体职责抽象出来，然后分离一些实现类，分别实现各自的功能。

 

4. 总结

学设计模式不容易，需要熟悉语言、面向对象、理解设计原则。。。。即便是都看会了，理解了，到了应用又是个麻烦事儿。

有一位大牛说过：《设计模式》这本书，我们要像字典一样经常拿出来翻翻看看，而不是通篇看完就算了。

可见，它需要我们长期的“学习 - 应用 - 总结 - 学习”，才能更好的理解。

 

另外，我感觉在系统设计中，也没有必要非得去套用设计模式，只要符合设计原则，符合开发、运行效率，怎样设计都行，不要为了用而用，滥用不如不用。

话又说回来，还是对设计大原则，对“道”的理解。