面向对象编程和设计模式的七大原则理解

1 单一职责原则

       名称很形象，字面意思就是一个对象只负责一件事情。这里针对的具体的实现可以把看作一个class。如果一个对象o负责处理两件事情p1和p2，p1和p2任何一个需求发生变化都会导致修改对象o，当符合单一职责原则时就不会发生这种耦合。项目开始我们很容易遵循此原则，但是需求是瞬息万变的。当需求增加时，在修改方便和节省时间等因素的诱惑下我们是否还能保持此原则是一个未知数，但我们要做的是在对象失控之前去重构代码。

2 开闭原则

     简单的理解为对扩展说yes，对修改说no。当我们的需求变化时通过继承或者编写兄弟子类的方式解决问题，而不是通过直接修改源代码。这样能降低出错的风险。

3 里氏置换原则

    当一个对象a替换为另外的对象b时，程序能正常运行。一般情况下a是一个基类或者接口，而b是a的一个子类。所以需要我们把基类或者接口作为声明的对象，在实例化时根据需求生成对应的子类，而这个实例化对象可以被任何其它子类代替，此时就满足了里氏置换原则，因为子类包含了基类的所有方法。如果声明的对象是兄弟子类，这两个对象不一定包含对方的全部方法，所以不能置换。如果是不同的对象，显然也不符合本原则。

4 依赖倒置原则

    这个原则在开发过程中用的非常多，也是非常重要的一个原则。先看一个简单的例子，当a依赖于b的一部分，b依赖于c的一部分，这样a就间接的依赖于c的一部分。当a的需求（依赖c的成员）改变时，需要同时修改b和c。可以想象如果对象有n层依赖，当修改起来时会非常繁琐。恰恰依赖倒置原则帮我们解决了这个问题，只要把a和b的依赖抽象成接口i，i只负责规定功能而不负责具体的实现，a和b分别依赖接口i，这样当a或b的需求改变时是需要修改自己就可以，不会对其他模块产生影响。

5 接口隔离原则

    这个原则也可以说成是最小接口原则，和依赖倒置原则密切相关。当接口i包含方法1，2，3，4和5，且对象a需求为1，2和3，对象b需求为2，3，4和5，但是a和b都需要实现1，2，3，4和5五个方法。很显然这里我们需要实现不需要的方法。所以接口i拆分为i1（方法2，3），i2（方法1）和i3（方法4，5），a依赖i1和i2，b依赖i1和i3，嗯这样就分离开了，不错，不错。具体的拆分程度根据需求具体分析吧，显然把i拆分为5个接口维护起来会比较困难，复杂度也会增加。

6 迪米特法则

    名字看起非常懵比，这是什么鬼-_-。说一下我的理解吧，这个原则主要说的一个对象a尽可能少的依赖其他对象，主要目的是减少耦合。因为每有一个依赖e发生改变那么就需要重构a。解决的方法是增加一个帮助对象h，a只依赖于这个帮助对象h，当依赖e发生变化时，修改h即可，不要修改a的主逻辑部分。这样减少了程序出错的几率。

7组合/聚合复用原则

    组合和聚合有什么区别呢？组合可以理解为汽车发动机里的所有零件之间的关系，它们一起作用组成了发动机，他们关系比较密切。聚合可以理解发动机和汽车底盘的关系，它们虽然也一起工作但它们是相对独立的模块，关系也不如发动机内部零件之间密切。在这里说的是通过把不同对象组合到一起协同工作，而不是通过继承的方式。需要注意的是，对象越多维护起来越繁琐，继承层次越多对象越臃肿。所以平衡是一门艺术。

结束语：所有知识来源于互联网，回馈于互联网。这里只是自己的一些理解，一段笔记。如有错误欢迎指正。