设计模式中的六大基本原则

软件设计中的基本共识：

1.高内聚，低耦合：如果想使软件系统架构稳定那么我们期望软件的各模块内元素结合的紧密，而模块之间的耦合度（关联性）越低越好。高内聚不仅体现在模块上，单独的类或方法也应该是内聚的。

2.面向抽象编程：面向过程开发中，上层组件调用下层组件，这意味着当下层组件发生剧烈变化时，上层组件也得跟着一起变化，增加了维护成本。面向对象的设计中，我们努力使程序依赖抽象，而不去依赖具体实现，首先依赖抽象降低了模块间实现细节的耦合度，其次抽象变化的概率比较小，修改具体实现不影响其他模块，见底了风险成本，提升了软件结构的健壮性。

3.多用组合少用继承：组合和继承都是对已有属性和功能的复用，继承偏向于扩展，组合偏向于使用。组合的好处在于其方式更加灵活，不会对类造成危害，不会造成膨胀，同时减少了对父类的依赖。少用继承而不是不用继承，使用继承结构的代码可读性更高，一般认为继承结构不应该超过4层，而且应该谨慎的使用修饰符【附1】。

4.开闭原则：软件设计中主张“对扩展开放，对修改关闭”，该原则倡导我们队软件实体进行拓展时，尽量不要去修改原有的软件实体进行修改。

对以上共识具体化和规范化就有了设计模式的六大原则：

1.开闭原则：一个软件实体应该对扩展开放，对修改关闭。

2.单一职责原则：一个类应该只有一个引起它变化的原因。

3.依赖倒置原则：要依赖要抽象，而不要依赖于具体实现。

4.接口隔离原则：使用多个隔离的接口，分离不同的借口行为，也就是说一个类对另外类的依赖性应该建立在最小接口上。

5.里氏替换原则：继承必须保证基类所拥有的性质在子类中仍然成立，即子类应当替换任何基类能够出现的地方。

6.迪米特法则：只和密友交谈。即一个软件实体应该尽可能少的与其他实体发生相互作用。

本篇文章主要是用来回顾下软件设计中的各个原则，也就没有Po上代码来做演示（主要是演示设计模式的代码量有点大），谈谈个人对六大原则的看法：

开闭原则告诉我们新增一个类而不是修改原有类来达到迭代效果，但是很遗憾现实中很难做到，首先该原则的前提是软件一开始就有一个很好的架构，研发人员都精心的维护这个架构，其次要求产品部懂得这个架构，不去提特别妖娆的需求。

单一职责原则，还是很好理解并且值得我们注意的，保证模块的单一职责想必大多数程序员都可以做到，方法的单一职责也很好理解，但是大多数人却没有做好：表现在一个公共方法被分解成了私有的几个独立的子方法，而子方法里面居然可以继续往下分好几层，那么这些子方法真的是单一职责么，如果真的必要这样，是不是可以用上下文参数来减少分层，顺带说一句随意分层的代码还严重降低了可读性。

依赖倒置原则和接口隔离原则，确保你有一个好的抽象接口，而一般好的接口总是最小的，检验的方法就是看看你接口的实现类是不是真的需要实现每一个方法。

里氏替换原则，子类应当替换任何基类能够出现的地方。

迪米特法则，在实践中没有具体运用到，但是还是能够想到的，我引用的类越少，那么可能导致我做改变的因素就越少。

附：1.JAVA 修饰符作用范围