六大设计原则

简介: 单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则

单一职责原则

定义:

       职责是指变化的原因,一个类应当有且仅有一个引起它变化的原因,否则会这类就需要被拆分。

优点:

       1. 降低类的复杂度。一个类只负责一项职责,其逻辑肯定要比负责多项职责简单得多。

       2. 提高类的可读性。复杂性降低,自然其可读性会提高。

       3. 提高系统的可维护性。可读性提高,那自然更容易维护了。

       4. 变更引起的风险降低。变更是必然的,如果单一职责原则遵守得好,当修改一个功能时,可以显著降低对其他功能的影响。

缺点:

       1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力;

       2. 当客户端需要该对象的某一个职责时,不得不将其他不需要的职责全都包含进来,从而造成冗余代码或代码的浪费。

里氏替换原则

定义:

       所有引用积累的地方必须能透明地使用其子类的对象,子类可以替换掉父类而不产生任何异常或错误,而父类不一定能代替子类。

四层含义:

       1. 子类必须完全实现父类方法

       2. 子类可以有自己的个性

       3. 覆盖或实现父类的方法使输入参数可以被放大

       4. 覆写或实现父类的方法时输出结果可以被缩小

依赖倒置原则

定义:

       将原本的依赖进行抽离,使得高层模块不再依赖低层模块,而是共同依赖抽象模块。

三层含义:

       1. 高层模块不应该依赖底层模块,两者都应该依赖其抽象

       2. 抽象不应该依赖细节

       3. 细节应该依赖抽象

规则:

       1. 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备:这是依赖倒置的基本要求,接口和抽象类都是属于抽象类的,有了抽象才可能依赖倒置。

       2. 变量的表面类型尽量是接口或者抽象类:并不是变量的类型一定要是接口或者抽象类,比如一个工具类,xxxutils一般是不需要接口或是抽象类。还有,如果使用类clone方法,就必须使用实现类,这个是JDK提供的一个规范。

       3. 任何类都不应该从具体类派生:如果一个项目处于开发状态,确实不应该有从具体类派生出子类的情况,但人总会犯错,因此不超出两层的继承都是可以忍受的。

       4. 尽量不要覆写基类的方法:如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。

       5. 综合里氏替换原则使用。

接口隔离原则

定义:

       将不同职责的接口进行隔离,划分接口粒度,不要违反单一职责原则,不要划分大量的接口,影响使用。

四层含义:

       1. 接口要尽量小:这是几口隔离原则的核心定义,不出现臃肿的接口(fat interface),但是“小”是有限度的,首先就是不能违反单一职责原则。

       2. 接口要高内聚:就是提高接口,类、模块的处理能力,减少对外的交互。

       3. 定制服务:单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求:只提供访问者需要的方法。

       4. 接口设计时有限度的:接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度增加。可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度。

迪米特法则

定义:

       一个类应该只需要了解你调用的方法,而不需要了解类内部的结构,在功能完成的基础上了解最少的信息。

优点:

       1.类间解耦,提高类的复用率。

缺点:

       1.产生了大量的中转和跳转类,导致系统的复杂性提高,同时也为维护带来了难度。

开闭原则

定义:

       1.一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

重要性:

       1. 开闭原则对测试的影响:测试时出错,测试失败时。通过扩展来实现业务逻辑的变化,而不是修改。

       2. 开闭原则可以提高服用性:在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来的,而不是在一个类中独立实现一个业务逻辑。只有这样的代码才可以复用,粒度越小,被复用的可能性越大。

       3. 开闭原则可以提高可维护性。

如何使用:

       抽象约束:抽象是对一组事物的通用描述,没有具体的实现,也就表示它可以有非常多的可能性,可以跟随需求的变化而变化。因此通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放,包含三层含义:第一,通过接口或抽象类约束扩展,对扩展进行辩解限定,不允许出现在接口或抽象类中不存在的public方法;第二,参数类型、引用对象尽量使用接口或者抽象类,而不是实现类;第三,抽象层尽量保持稳定,一旦确定即不允许修改。

       元数据(metadata)控制模块行为:使用元数据来控制程序的行为,减少重复开发。什么是元数据:用来描述环境和数据的数据,通俗地说就是配置参数,参数可以从文件中获得,也可以从数据库中获得,即通过参数来控制模块行为。

       制定项目章程:在一个团队中,建立项目章程是非常重要的,因为章程中制定了所有人员都必须遵守的约定,对项目来说,约定优于配置。

       封装变化:对变化的封装包含两层含义:第一,将相同的变化封装到一个接口或抽象类中,第二,将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中,封装变化也就是受保护的变化(protected variations),找出预计有变化或不稳定的点,我们为这些变化点创建稳定的接口,准确的讲是粉装可能的变化。

目录
相关文章
|
2月前
|
设计模式 前端开发 Java
设计模式之六大基本原则
设计模式之六大基本原则
27 0
|
10月前
|
数据安全/隐私保护
七大设计原则之单一职责原则应用
七大设计原则之单一职责原则应用
42 0
|
2月前
|
设计模式 Java 数据安全/隐私保护
设计模式之六大设计原则
设计模式之六大设计原则
37 0
|
2月前
|
设计模式 程序员
软件设计模式:六大设计原则
软件设计模式:六大设计原则
|
2月前
|
设计模式 存储 自然语言处理
Java面向对象设计七大原则
Java面向对象设计七大原则
90 0
|
2月前
|
存储 关系型数据库 uml
00003.七大软件架构设计原则
00003.七大软件架构设计原则
49 0
|
10月前
|
开发者
构建可持续性软件架构:六大设计原则
构建可持续性软件架构:六大设计原则
200 0
|
12月前
|
设计模式 架构师 Java
五大(七大)原则-系统学习三
小编自涉足程序园界几千天之多;对于设计原则的学习一直在努力从未见到顶。最近又将设计原则从宏观和微观的角度进行了对比学习;仅以此将自己的学习过程和收获做如下总结,
|
设计模式 数据库
面向对象的七大设计原则
面向对象的七大设计原则
272 0
|
Java 关系型数据库
java面向对象设计的五大原则
java面向对象设计的五大原则