设计模式原则

近期看了大话模式这本厚重的书，看完了之后感觉就是这本书里面那么多的模式，感觉他们之间好像都没有很大的差别。初期的印象就是秉着面向对象的思想努力提高内部的内聚性，以及和外界之间的松耦合性。那这种软件标准该如何实现呢？这就需要我们在开发当中充分利用设计模式的原则。

 

NO.1单一职责原则

这个相信我们在生活中用的比较多，就例如现在的学习就是在一个番茄的时间内集中注意力完成某一件事情。代码如人生，如果一个类承担了太多的责任，无法避免的就会出现耦合的状况，这不利于软件的健壮性。但是这并不意味着软件设计只需要实现一个功能就OK了，其实只是在开发过程中可以根据他们的功能分离出多个类，每个类只承担一项责任。

 

NO.2开放—封闭原则

这里的开放是指的软件实体类或者方法可以拓展，封闭则是指的对原来的方法或者类不可以修改。为什么要这样呢？这其实就是考虑到了在大型软件开发过程中你若是对原来的代码进行修改，那极有可能就会出现牵一发而动全身的现象，这样的话修改的工程量实在是太大了。其实这个现在理解起来还是比较简单的，就例如现在的软件更新我想就是基于这个原则实现的。

 

NO.3依赖倒转原则

此原则的基本要求就是：

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

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

说实话，这个到现在还是有点迷糊。希望谁要是有好的想法，能够互相沟通沟通。

 

NO.4里氏代换原则

这个原则就是说子类能够完全继承父类，替代父类。

例如生活的小例子：市场上有2.0的U盘还有3.0的U盘，他们俩就是父子类的关系。3.0的U盘完全继承了2.0U盘的功能，此外它还有自己新的功能，写入写出的速度快。

 

NO.5迪米特原则

这个原则的前提就是在类的结果设计上，每一个类都应当尽量降低成员的访问权限。说的简单点就是每个类要做好包装，留个接口和外界交流就可以了。举个小例子就是你家热水器坏了，打电话给修理公司，他们就会派个业务员过来帮你弄。至于这个业务员是谁，至于你跟业务员之间熟不熟那就完全不用担心。你只要家里电器能被修好就行。从这个例子看来，它里面就有修理公司这个中介调用业务员修理电器产品，减少了客户和业务员之间的耦合性。其实看到这原则再联系一下中介者模式，我相信理解会更进一层的。

 

总结：看了这些原则之后再去看书上的设计模式，你会发现那么多的设计模式之间都特别的像，只不过是根据不同的情况，采取不一样的设计模式而已罢了。