设计模式原则之我见

OCP(open-close-principle)开闭原则【最核心的法则】：

对扩展开发，对修改关闭；就是说不允许修改的是抽象类和接口，允许扩展的是具体的实现类。

举个简单的例子：比如一个系统里有分类这个概念，比如人与分类有关联，书籍与分类有关联，文章与分类也有关联...当需要查找某个人的分类时，就会在分类的service写个方法，来获取人的分类信息，当需要查找某本书的分类信息时，继续在分类的service里边添加另一个查找书籍分类的方法，照这样下去，这个类就会膨胀，没完没了，这就违反了开闭原则。可以采用分离的方法来解决这个问题：建一个分类的service接口，定义好需要的公用方法（这里是查找分类信息），然后建立对应的实现分类service接口的实现类，如PersonServiceImpl，这个专门用来查找人的分类，创建BookServiceImpl专门用来查找书籍的分类信息；OCP中，抽象化是关键，将可变的因素分块封装起来，避免超大类，超长类，超长方法。

 

LSP（Liskov Substitution Principle）里氏替换原则：

任何基类可以出现的地方，子类也可以出现。

尽量不要重写父类已经实现的方法，如果一定要重写，那么可以将原来的父类和子类都继承一个通用的基类，然后把原来的继承关系去掉。

 

接口隔离法则：使用对个专门的接口比使用单一的总接口要好

 

迪米特法则：一个对象对其他对象应该有最少的了解

 

依赖倒转原则：针对接口编程，不针对实现编程

 

单一职责原则：对于类尽量做到单一职责，但是对于方法一定要做到

 

----------------待续