关于设计模式的几点经验分享

前言

设计模式大家都很熟悉，什么简单工厂模式，抽象工厂模式，命令模式，适配器模式几乎每个开发人员都能说出个一大堆来，但到实际应用时又往往难以落地，或被滥用，本周有幸去参加大胡子的两天的设计模式的课，感觉还是收获颇丰，在这里我就把课程结合自身的一些经验介绍一下。

设计的原则

在做程序设计的时候需要遵从一些基本原则，比较公认的就是S.O.L.I.D.原则，即单一职责原则，开闭原则，里氏替换原则、接口隔离原则，依赖倒置原则。下面就分别聊聊这几个原则。

单一职责原则

单一职责原则还是很好理解的，每个程序或函数都应该只负责一件事情，怎么分辨是否违反了这一原则呢？其实很简单，就是在命名时来看是不是想起一个带有And或是Manager的名字，如果是就应该考虑该函数或模块能否进一步拆分，来分离相应的职责。
怎么减少违反这个原则呢，有一个行之有效的方法就是测试驱动开发（TDD）以后会有专门的文章案例介绍TDD。

开闭原则

开闭原则就不是那么直白了，原话是程序应该对扩展是开放的，而对变化是封闭的。
有一个例子可以很好的说明这个原则，比如说开发一个程序是把大象放到冰箱里，程序运行的很不错，老板又让将将老虎和狮子放到冰箱里的程序，你改把刚刚的程序改了改很快就投入使用。但是这样的程序是违反了开闭原则，因为把老虎和狮子放到冰箱里实际上与把大象放进冰箱里并没有什么不同，只是一种扩展，但还需要改变程序因此违反了开闭原则。正确的做法应该是不应该把直接把大象放入冰箱，而是把动物放进冰箱里，这样狮子老虎都是属于动物，都可以直接用这个程序完成任务，不需要修改。这样就满足了开闭原则。

里氏替换原则

即子类型一定能替换付类型但反之则不然。

还是刚刚的例子，大象和动物类之间的关系就是子类和父类的关系。我们的程序中设计的是将动物放入冰箱里，这时我们使用大象来替换动物程序运行正常，但在另一个程序中描述大象的鼻子长又长能用来洗澡，但换成其他动物就不行了。

接口隔离原则

官方的说法是客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。这个原则其实就是最小知识原则，一个程序所需要具备的知识应该是尽量少的，这样它与其他部分的耦合就尽量降低。
实际中就是不依赖从未使用的功能。从这里可以考虑WebService并不满足这一接口要求。

依赖倒置原则（DI）

官方说法：
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
更直白一点是依赖抽象而不依赖于具体，依赖于意图的定义而不是依赖意图的实现。

在实际系统中意图的定义往往是不变的，而意图的实现往往是变化多端的。如：我们可能通过mysql，sqlserver，或postgresql来存储数据这个是可能变化的，但是我们想将数据存储到数据库中，从数据库中进行检索，修改数据库中的数据，以及删除数据这些意图是不会出现变化的。

总结

1.除了这几设计原则还有一个重要的原则就是DRY（Do not repeart yourself）.
2.在实际中这些原则往往不是孤立而是相互关联的，通常都围绕着高内聚，低耦合这一理念而展开的。
3.设计模式不是凭空造出来的，而是在程序的开发过程中不断的抽象和重构总结出来的，因此设计模式一定要了解但不可乱用，设计模式往往是处理重复代码以及容易变化或扩展点的神兵利器。