网上很多分析设计原则的文章,有些大神写得非常好,有例子,有说明,深入浅出,本人此处只列出几个普遍通用的设计原则,讲一下我的理解,代码实现需读者自行验证。
总原则:开闭原则(Open Close Principle)
开闭原则就是说:对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。
所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类等,后面的具体设计中我们会提到这点。
1、单一职责原则(Single responsibility principle)
原理:不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,如若不然,就应该把类拆分。
此处多说一句:对于方法定义也理应如此,一个方法只干一件事。
违反后果:
a、当一个职责发生变化时,可能会影响其它的职责,多个职责耦合在一起,会影响复用性、 维护性、可扩展性。
b、类的职责不清晰,不符合高内聚设计要求。
2、里氏替换原则(Liskov Substitution Principle)
原理:里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
里氏替换原则的含义是:如果一个程序中所有使用基类的地方都可以用其子类来替换,而程序的行为没有发生变化,那么这个子类就遵守了里氏替换原则。换句话说,一个子类应该可以完全替代它的父类,并且保持程序的正确性和一致性。
里氏替换原则的目的是:为了保证继承关系的合理性和稳定性,避免出现继承层次混乱和子类过度扩展的情况
违反后果:
a、降低代码的复用性和可维护性,提高了程序的耦合度和复杂度。
b、子类改变了父类的行为,会导致程序出错。
3、依赖倒置原则(Dependence Inversion Principle)
原理:开闭原则的基础,具体内容是面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。
违反后果:
a、导致代码耦合度过高。
b、限制了代码的可扩展性。
c、如果高层模块依赖于低层模块,那么这两个模块之间的耦合度将非常高,而且修改其中
一个模块可能会影响到另一个模块。
扩允:引用一篇文章:2.3 依赖倒置原则 - 知乎 推荐阅读第2节什么要依赖倒置。
4、接口隔离原则(Interface Segregation Principle)
原理: 这个原则的意思是每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个接口上)要好。
该原则很好理解,不要把不相关的功能接口揉在一起,代码可不像乱麻,可以快刀斩掉。
违反后果:
a、接口定义模糊,代码混乱,可维护性差。
b、长期违反者,可能会被其他同事吐嘈,严重时会丢了饭碗。
5、迪米特法则(最少知道原则)(Demeter Principle)
原理:该法测是说一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。
最少知道原则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
说明一下:
该原则我发现在工作中很多同事都在犯,糊里糊涂地就犯了,我也不例外,主要原因有两点,一是在写代码的过程中需求方一天三催,充分表达了他们的责任心,时间紧迫,不管三七二十一,先完美犯错,二是开发者没有意识或经验不足,纵使前面是坑,也勇往直前。最后的后果就是出现重复代码,腐烂代码。
违反后果:
a、代码重复度高,冗余,后期维护难。
6、合成复用原则(Composite Reuse Principle)
原理: 原则是尽量首先使用合成/聚合的方式,(门面设计模式也是该思想)而不是使用继承。
个人感觉是用接口还是继承,要看具体场景,要符合语义:
接口语义表达:CAN-DO
抽象类语义表达:IS-A
违反后果:
a、过多使用继承,会使代码灵活性变差,当然合适的场景,还是推荐抽象类,选择更符合的方式来实现比较好。
7、奥卡姆剃刀原则
原理:奥卡姆剃刀原理的核心是简单性原则,这是一种哲学思想,用到软件设计就是常说的:“如非必要,勿增实体”。
建议读者在开发软件之前先想一想:
1. 做这个设计有没有必要?
2.设计这个东西目的是什么?
3.带来什么价值?
4.设计能不能再简单点?
5.有没有更优更好的方案?
灵魂拷问之下,答不上者,请慎重撸码。
违反后果:
a、随着业务增长,不加思考就增加实体,系统设计就会在开发过程中变得非常复杂臃肿,读者想想,是不是有时接到一个旧系统时有一丝想重写它的冲动?
b、还有一个严重的问题,复杂度达到一定程度后,前期开发就会前功尽弃。无意给后来者创造一个重写系统的机会,浪费了人力和物力。
个人见解,如有不妥,请评论留言,共勉之。