1,开闭原则 Open Closed Principle
软件实现应该对扩展开放,对修改关闭,其含义是说一个软件应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化的。
从需要抽象的角度来说,开闭原则和依赖倒置原则也有一定的相似性,不过博主觉得,开闭原则更加偏向的是使用抽象来避免修改源代码,主张通过扩展去应对需求变更,而依赖倒置更加偏向的是层和层之间的解耦。
https://zhuanlan.zhihu.com/p/24269134 很好的文章
2,单一职责原则 Single Responsibility Principle
引起类变化的原因不能多于一个。也就是说每一个类只负责自己的事情,此所谓单一职责。
单一职责通常意味着单一的功能,因此不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。
理解单一职责原则,最重要的就是理解职责的划分,职责划分的粒度取决于需求的粒度,最后又回到了那句话:没有最好的设计,只有最适合的设计。
https://zhuanlan.zhihu.com/p/24198903 很好的文章
3,依赖倒置原则 Dependency Inversion Principle
高层模块(业务逻辑)不应该依赖低层模块(库函数),两者都应该依赖其抽象;
高层模块直接依赖低层模块的实现:当高层模块的业务逻辑改变时,底层模块做出相应的扩展修改,高层模块拿到底层模块的修改内容,然后也做出修改。这种境况是荒谬的。
高层模块依赖于底层模块的抽象时:当高层模块的业务逻辑改变时,因为接口这个行为很少会改变,所以只需要底层模块做出相应的扩展修改,而高层模块不需要修改代码。这个时候,就好像依赖“倒置”了。
https://zhuanlan.zhihu.com/p/24175489 很好的文章
4,接口隔离原则 Interface Segregation Principle
类之间的依赖应该建立在最小的接口上面。何为最小的接口,即能够满足项目需求的相似功能作为一个接口,这样设计主要就是为了“高内聚”。那么我们如何设计最小的接口呢?那就要说说粒度的划分了,粒度细化的程度取决于单一职责原则里面接口划分的粒度。从这一点来说,接口隔离和单一职责两个原则有一定的相似性。
单一职责原则更加偏向对业务的约束,接口隔离原则更加偏向设计架构的约束。
https://zhuanlan.zhihu.com/p/24246822 很好的文章
5,里氏替换原则 Liskov Substitution Principle
一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常
解除代码耦合度,以达到,可复用,可扩展,可维护。
总结:设计一个类时就应该想到单一职责,合理的划分职责的粒度。然后考虑之后可能有哪些修改,即开闭原则,根据粒度定于出相应的抽象类,接口。定义抽象类或者接口时就需要根据粒度考虑里氏替换原则和接口隔离原则,最后使用时考虑依赖倒转原则,使用父类作为参数传递。