我对设计的基本原则的理解

1、单一职权原则

      “对应一个类而言，应该仅有一个引起它变化的原因”，也就是一个类的职权(提供)的功能要单一，别在一个类里把所有的事干了。我认为就是所谓的封装，所谓的高内聚。

2、依赖反转原则

     高层模版不应该依赖与底层模版，他们不应该依赖与具体的实现，而是应该依赖于抽象。抽象不应该依赖于细节。通俗的说，也就是你在一个类中，别依赖于具体的类，应该依赖于接口。至于怎么样实例化具体的类，答案是依赖注入，具体的实现是通过注入，实例化到高层模版的。创建该底层模版不是，高层模版的责任，而交给了框架，如spring。

3、开闭原则

     程序应该对修改关闭，对扩展开放，这原则好理解，就是别为了增加功能改以前的旧代码（不改不错嘛），你可以扩展。

4、里氏替换原则

      子类应该可以替换父类，这个我认为也好理解，只要你的程序符合原则2，也就是依赖于接口。你现在new的是猫，将来new的是狗。程序是不会受影响的（当然功能是变化了），因为他们暴漏的接口是一样的。

5、接口隔离原则

      我认为这个原则和原则1有点像。但描述的对象是接口（抽象）。譬如你对一个人的描述，runable、sleepable等等，会比run&sleepable强。当你需要跑的时候实现runable就行了。需要睡实现sleepable。神马？你需要边睡边跑？梦游？那你就实现两接口嘛。

     为神马要这样？俺认为就是为了复用，为了扩展。想象一下，一个人都比你拆成七零八落了。有一天你需要去银行办事。你可以是一个知道神马是银行的，会跑的人去做这事，也就是（跑去银行）。也可以是，一个知道银行的，会开车的人（开车去银行）。"知道银行"这部分代码就可以重用了。

6、迪米特原则

     迪米特原则也叫做“最少知识原则”。强调应该降低类和类之间的耦合，低耦合可以使得修改影响面降低到最低。譬如，你电话费扣错了，你只需要打10086，你依赖于10086，10086要找谁，这是你不需要关心的（你不需要懂，最少知识原则）。这样移动内部的变化，你就不需要管了，他们里面的流程变化神马变化都跟你没关系。

再想想我们找我们的公仆办事，办个小屁事，跑十几个部门。。。你依赖于10几个部门，蛋疼不疼，疼就记住这个原则吧。