大话设计模式学习（三）——四大原则

一 单一职责原则

就一个类而言，应该仅有一个引起它变化的原因。

我们在做编程的时候，很自然的就会给一个类增加各种各样的功能，比如我们写一个窗体应用程序，一般都会产生一个doc这样的类，于是我们会把各种各样的代码，像某种商业运算的算法啊，数据库访问的代码啊什么的都写到这样的类中，这就意味着，无论任何需求要来，你都需要更改这个类，这是很糟糕的，维护麻烦，复用基本不可能。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。

软件设计真正要做的事，就是发现职责并把哪些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

二 开放—封闭原则

开放-封闭原则，是说软件实体（类、模块、函数等）应该可以扩展，但是不可修改。具体说，这个原则包含两个特征：

1.对于扩展是开放的

2.对于更改是封闭的

怎样的设计才能面对需求的改变却可以保持相对稳定，使得系统在第一个版本以后不断推出新的版本呢？最好的办法，就是多扩展，少修改。涉及的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改了，如果新的需求来，增加一些类就完事了，原来的代码能不动则不动。

无论模块是如何的封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须猜测出最有可能发生的变化种类，然后构造抽象来隔离哪些变化。在我们最初写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化，查明可能发生的变化所等待的时间越长，要创建正常的抽象就越难

开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象所声称的巨大好处，也就是可维护，可扩展，可复用，灵活性好。开发人员应该仅对程序中呈现出频繁变化的那部分作出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象一样重要。

三 依赖倒转原则

1.高层模块不应该依赖底层模块。两个都应该依赖抽象

2.抽象不应该依赖细节，细节应该依赖抽象

面向过程的开发中，为了使得代码可以复用，一般会把常用代码写成许许多多函数的程序库，这样我们在做新的项目时，去调用这些底层的函数就可以了。比如我们做的项目大多数要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新的项目时就去调用这些函数。这就是高层模块依赖低层模块



问题也就出在这里，我们要做新项目时，发现业务逻辑的高层都是一样的，大客户却希望都不同的数据库或存储信息方式，这时候就出现麻烦了，我们希望能再次利用这些高层模块，但是高层模块都是与低层的访问数据库绑定在一起的，没办法复用这些高层模块，这就糟糕了。

不管高层还是低层模块，他们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就是的无论高层还是低层模块都可以很容易被复用，这才是最好的办法。



依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了

四 里氏代换原则

子类型必须能够替换掉他们的父类型

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而他察觉不出父类和子类的区别。也就是说，在软件里面，把父类都替换成他的子类，程序的行为没有变化。正式由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下才可以扩展