软件设计七大原则

172 阅读6分钟

@TOC 软件设计七大原则: 学习设计原则是学习设计模式的基础。在实际开发过程中,千万不能形成强迫症。碰到业务复杂的场景,我们需要随机应变。并不是一定要求所有代码都遵循设计原则,我们要考虑人力、时间、成本、质量,不是刻意追求完美,要在适当的场景遵循设计原则,体现的是一种平衡取舍,帮助我们设计出更加优雅的代码结构。

开闭原则(Open-Closed Principle)

开闭原则,对扩展开放,对修改关闭 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 定义补充:用抽象构建框架,用实现扩展细节 优点:提高软件系统的可复用性以及维护性

里氏替换原则(Liskov Substitution Principle)

里斯替换原则,将父类对象替换为子类对象时,程序没有影响 子类可以拓展父类的功能,不能改变父类原有的功能,杜绝继承泛滥 子类可以扩展父类的功能,但是不能改变父类原有的功能,杜绝继承泛滥 定义:任何父类可以出现的地方,子类一定可以出现。 定义补充:里氏代换原则是对“开-闭”原则的补充。 引申意义:子类可以扩展父类的功能,但不能改变父类原有的功能。 含义1:子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。 含义2:子类中可以增加自己特有的方法。 含义3:当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松。 含义4:当子类的方法实现父类的方法时(重写/重载或实现抽象方法)方法的后置条件(即方法的输出/返回值)要比父类更严格或相等。 优点:

约束继承泛滥,开闭原则的一种体现。 加强程序的健壮性,同时变更时也可以做到非常好的兼容性、提高程序的维护性、扩展性。降低需求变更时引入的风险。

依赖倒置原则(Dependence Inversion Principle)

依赖倒置原则,高层模块不应该依赖低层模块,二者都应该依赖其抽象 通过抽象实现各个类(各个模块)之间相互不影响,实现松耦合,面向抽象编程接口编程 通过抽象实施各个类各个模块之间相互不影响,实现松耦合,尽量面向抽象编程,面向接口编程 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象 定义补充:抽象不应该依赖细节,细节应该依赖抽象 针对接口编程,不要针对实现编程 优点:可以减少类间的耦合性、提高系统稳定性,提高代码可读性和可维护性,可降低修改程序所造成的风险

单一职责原则(Simple Responsibility Pinciple)

单一职责原则,一个类负责一个职责 一个类(一个接口/一个方法)只干一件事 一个类一个接口,或者说一个方法只干一件事 定义:不要存在多于一个导致类变更的原因 定义补充:一个类/接口/方法只负责一项职责 优点:降低类的复杂度、提高类的可读性,提高系统的可维护性、降低变更引起的风险

接口隔离原则(Interface Segregation Principle)

接口隔离原则,用多个专门的接口,而不使用单一的总接口 接口设计纯洁,要非常的单一,只干某一类事情,不应该依赖不需要的接口 接口面向抽象基础上,接口设计要纯洁,一个接口要单一,只干某一类事情,不应该依赖不需要的接口 定义:用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口 定义补充:

一个类对一个类的依赖应该建立在最小的接口上 建立单一接口,不要建立庞大臃肿的接口 尽量细化接口,接口中的方法尽量少 注意适度原则,一定要适度 优点:符合我们常说的高内聚低耦合的设计思想,从而使的类具有很好的可读性、可扩展性和可维护性。

接口隔离原则与单一职责异同: 接口隔离原则约束的接口依赖的隔离。针对的是抽象。 单一职责原则约束的是类/接口/方法的职责是单一的,强调的是职责。针对的是程序中的实现和细节。

迪米特法则(Law of Demeter)

迪米特法则,一个对象应该对其他对象保持最少的了解 最少知道原则,一个类对其所依赖的类知道的越少越好,提升代码可读性 最少知道原则,一个类其所依赖的类知道的越少越好,提升可读性 定义:一个对象应该对其他对象保持最少的了解,使得系统功能模块相对独立,这样当一个模块修改时,影响的模块就会越少,扩展起来更加容易。又叫最少知道原则 定义补充:尽量降低类与类之间的耦合 优点:降低类之间的耦合 强调只和朋友交流,不和陌生人说话 朋友:出现在成员变量、方法的输入、输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类

合成复用原则(Composite/Aggregate Reuse Principle)

合成复用原则,尽量使用对象组合,尽量不用继承 尽量使用对象组合聚合而不使用继承关系达到代码目的, 与依赖倒置原则首位呼应 使用对象组合聚合,而不使用继承的关系 定义:尽量首先使用合成/聚合的方式,而不是使用继承。 优点:可以使系统更加灵活,降低类与类之间的藕合度一个类的变化对其他类造成的影响相对较少