软件设计原则详解

当我们在进行软件设计时,首先我们要充分地调查、收集用户的需求,今天老师说的一句话让我很受启发:变是永远不变,相对于我们的程序设计而言,用户的需求是时刻在变得,那我们怎样做才能满足客户的各种需求呢,众所周知,当我们的程序满足设计模式的六大原则时,程序会更加灵活,下面是小编对六大原则的理解:

单一职责原则:Single Responsibility Principle

定义:一个类只负责一项职责

就一个类而言,仅有一个引起它变化的原因,小编遇到的最大的问题是对职责的定义,什么是类的职责,以及怎么划分类的职责,这需要靠个人经验界定。

目的:降低类的复杂性,可读性提高,可维护性提高。

里式代换原则:Liskov Substitution Principle

定义:子类继承父类,单独完全可以运行

任何基类出现的地方,子类一定可以出现。LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加行的行为。

举例:球类,原本是一种体育用品,他的衍生类有足球、篮球等等,如果衍生类替换了基类的原本方法,如把体育用品改为了食用品(那么软件单位的功能受到影响),就不符合历史代换原则。

目的:对实现抽象化的具体步骤的规范。

依赖倒转原则:Dependence Inversion Principle

定义:高层模块不应该依赖底层模块,两个都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象

该原则针对接口编程,而不是针对实现编程,引用一个对象,如果这个对象有底层类型,直接引用底层类型。

举例:以计算机系统为例,无论主板、CPU、内存、硬件都是针对接口设计的,如果针对实现设计,内存就要对应到针对某个品牌的主板,那么如果需要换内存必须得吧主板也换掉,不符合设计原则。

目的:降低模块间的耦合度。

接口隔离原则:InterfaceSegregation Principles

定义:一个类对另一个类的依赖应建立在最小的接口上

为每个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类调用,客户端也不应该依赖它不需要的接口,每一个接口应该是一种角色。

举例:登陆和注册属于用户模块的两个接口,比写成一个接口好。

目的:提高程序设计的灵活性。

注:接口尽量小,但是要有限度。接口太小会造成接口数量过多,是设计复杂化,所以接口要适度。

迪米特原则:Law of Demeter

定义:一个实体应当尽量少的与其他实体之间发生相互作用

迪米特原则也叫”最少知道原则“,一个对象应对其他对象有尽可能少的了解(只与你的直接朋友交谈,不跟“陌生人”说话)。

举例:一个公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险也就越大。

目的:降低类之间的耦合,减少对其他类的依赖。

开闭原则:Open Close Principle

定义:对拓展开放,对修改关闭

猜你喜欢

转载自blog.csdn.net/TGB_Tom/article/details/112711924

相关文章