Java设计模式常用原则解析

1.单一职责原则 每一个类负责一个职责(一个类只有一个方法)

2.里氏替换原则 所有引用基类的地方都能透明的使用其子类的对象。

  问题来了:

  比如原来

  class A{
    fun();//完成P1功能
  }

  现在需要添加新功能

  class B extends A{//A的子类B实现了fun的功能)
    fun();完成功能为P(原来的P1功能加上新增的P2功能)
  }

  则,在子类B完成新功能P2的时候可能会导致原有功能P1发生故障

  解决办法

  当使用继承的时候,除了添加新的方法来完成新功能P2之外,尽量不要重写父类A的方法,也尽量不要重载父类A 的方法

3.依赖倒置原则(核心思想,面向接口编程)

定义:高层模块不应该以来底层模块,二者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象;

问题:

  类A(高层模块)直接依赖B(低层模块)

eg:class A{
    public void fun(B b){};
  }

  现在想要把类A的依赖改为C,则必须修改类A的代码为

eg:class A{
    public void fun(C c){};
  }

  解决办法:

  类B和类C都实现接口Interface D;

  类A依赖接口D

 eg:class A{
    public void fun(D d){};
   }

  这样在使用类A的fun方法时可以这样使用fun(new B());或者fun(new C());

4.接口隔离原则

将臃肿的接口才氛围独立的几个接口,这样子类在实现该接口时就不必要实现臃肿接口的所有的抽象方法

5.迪米特法则(最少知道法则)

  降低类与类之间的耦合度,从而减少当一个类改变时对另一个类造成的影响。

  简单来说,就是一个类对自己以来的类知道的越少越好。对于被以来的类,无论逻辑多么复杂,尽可能的将逻辑封装在类的内部,对外提供一个public的方法就行了。

  更简单的定义:至于直接的朋友(称出现成员变量、方法参数、方法返回值中的类为直接朋友,出现在局部变量中的类不是直接的朋友)进行通信。

  (依赖的三种方式,方法参数,局部变量-方法内的变量,静态变量-方法中调用某个类的静态方法)

6.开闭原则

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

  问题:当软件升级维护时,队友俺有代码进行修改,可能会给旧代码引入错误。

  解决办法:当软件需要变化时,尽可能通过扩展软件实体的行为来实现变化,儿不是通过修改已有的代码来实现变化。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Java中的设计模式与7大原则归纳整理

    Java中的设计模式与7大原则: 一.创建型模式 1.抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类. 2.生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示. 3.工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是

  • 举例解析Java的设计模式编程中里氏替换原则的意义

    里氏替换原则,OCP作为OO的高层原则,主张使用"抽象(Abstraction)"和"多态(Polymorphism)"将设计中的静态结构改为动态结构,维持设计的封闭性."抽象"是语言提供的功能."多态"由继承语义实现. 里氏替换原则包含以下4层含义: 子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法. 子类中可以增加自己特有的方法. 当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更

  • 实例讲解Java设计模式编程中的OCP开闭原则

    定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.          开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,它

  • 浅谈Java设计模式之开放封闭原则

    写在前面 最近, 接手了一个新业务,系统的架构可圈可点.但有些地方让人望而生畏,有些代码臃肿难以维护,让人不敢恭维.于是,结合了Java的开放封闭原则,对其中一部分代码进行了重构优化. 先来看下以前系统的老代码 ShareChannelManager.java public ResultDO<String> shareChannel(int shareCode) { if(ShareCodeUtil.share2A(shareCode)) { // TODO, 分享到A渠道的业务逻辑代码 }

  • 简单讲解Java设计模式编程中的单一职责原则

    单一职责原则:一个类,只有一个引起它变化的原因. 为什么需要单一职责原则? 如果一个类有多个原因要去修改它,那么修改一个功能时,可能会让其他功能产生Bug,所以一个类最好只有一个职责.但实际应用中还是比较难实现的,我们只能是尽量符合这个原则. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下面是个例子: packag

  • 详解Java设计模式编程中的里氏替换原则

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 定义2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来:有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成.新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决方

  • 简单理解遵循接口隔离原则的Java设计模式编程

    定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接口I中的方法1.方法4.方法5,类D是

  • 解析Java编程中设计模式的开闭原则的运用

    开闭原则(Open Closed Principle)是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统. 定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. Softeware entities like classes,modules and functions should be open for extension but closed for modifications. 开闭原则的含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码

  • Java设计模式常用原则解析

    1.单一职责原则 每一个类负责一个职责(一个类只有一个方法) 2.里氏替换原则 所有引用基类的地方都能透明的使用其子类的对象. 问题来了: 比如原来 class A{ fun();//完成P1功能 } 现在需要添加新功能 class B extends A{//A的子类B实现了fun的功能) fun();完成功能为P(原来的P1功能加上新增的P2功能) } 则,在子类B完成新功能P2的时候可能会导致原有功能P1发生故障 解决办法 当使用继承的时候,除了添加新的方法来完成新功能P2之外,尽量不要重

  • Java设计模式常用的七大原则总结

    一.设计模式常用的七大原则 单一职责原则:一个类应该只负责一项职责 接口隔离原则:客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上 依赖倒转原则 里氏替换原则 开闭原则 迪米特法则 合成复用原则 二.单一职责原则 1. 单一职责原则注意事项和细节 降低类的复杂度,一个类只负责一项职责 2.提高类的可读性,可维护性 3.降低变更引起的风险 4.通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则:只有类中方法数量足够少,可以在方法级别

  • 示例解析java设计模式七大原则接口隔离原则及优化

    目录 1.什么是接口隔离原则? 2.对应代码 3.改进代码 4.接口隔离原则总结 1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void oper

  • JAVA设计模式零基础解析之单例模式的八种方式

    目录 单例模式简介: 单例模式优点: 应用场景: 单例设计模式的八种方式: 1.饿汉式(静态常量) 2.饿汉式(静态代码块) 3.懒汉式(线程不安全) 4.懒汉式(线程安全,同步方法) 5.懒汉式(线程安全,同步代码块) 6.双重检查(推荐使用) 7.静态内部类(推荐使用) 8.枚举(推荐使用) 单例模式在JDK应用的源码分析 单例模式注意事项和细节说明 单例模式简介: 单例模式(Singleton Pattern)是 Java 中最简单的设计模式之一.这种类型的设计模式属于创建型模式,它提供了

  • Java设计模式七大原则之迪米特法则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 迪米特法则(Law of Demeter, LoD)是1987年秋天由lan holland在美国东北大学一个叫做迪米特的项 目设计提 出的,它要求一个对象应该对其他对象有最少的了解,所以迪米特法则又叫做最少知识原则. 案例 需求 有一个公司,下属有各个部门,现要求打印出公司员工的ID和部门员工的ID 方案一 定义公司员工类 /** * 公司员工 * @author:liyajie * @createTime:2022/2/8 11:

  • Java设计模式七大原则之单一职责原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 如何遵守单一职责原则 定义 单一职责原则(Single Responsibility Principle, SRP),有且仅有一个原因引起类的变更.简单来说,就是针对一个java类,它应该只负责一项职责.例如一个Test.java类,它有两个职责:职责1,职责2.当职责1进行修改时,有可能影响到职责2,所以需要将Test.java类拆分成Test1.java和Test2.java两个单一职责的类. 案例 需求 有一个交通工具类,里面定义一个

  • Java设计模式七大原则之里氏替换原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 里氏替换原则(Liskov Substitution Principle,LSP),官方定义如下: 如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象 o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型,所有引用基类的地方必须能透明地使用其子类的对象.则通俗的来讲:子类可以扩展父类的功能,但是子类不能修改父类原有的功能 里氏替换原则就是给继承性的使用制定了规范 案例 需求

  • Java设计模式七大原则之合成复用原则详解

    目录 定义 案例 需求 方案一 方案二 方案三 对比分析 总结 设计原则的核心思想 定义 合成复用原则(Composite Reuse Principle),即尽量使用组合/聚合的方式,而不是使用继承. 案例 需求 现在假设有一个A类,里面有两个方法,有一个B类,想要复用这两个方法,请问有几种方案 方案一 继承的方式 定义A类,并定义两个方法 /** * 类A * @author:liyajie * @createTime:2022/2/9 9:50 * @version:1.0 */ publ

  • Java设计模式七大原则之依赖倒置原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,即:上层模块不应该依赖底层模块,它们都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象.抽象对代码来说即接口或者抽象类 细节对代码来说即实现类.换句话说 依赖倒转原则的核心的理念 相对于细节来说,抽象要稳定得多.要求我们 面向接口编程,进行设计. 案例 需求 工作人员接收微信老板发来的加班消息 方案一 定义工作人员W

  • Java设计模式七大原则之接口隔离原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 小知识点 相同点 不同点 定义 接口隔离原则(Interface Segregation Principle),又称为ISP原则,官方定义为 1.客户端不应该依赖它不需要的接口 2.类间的依赖关系应该建立在最小的接口上 简单点来讲就是在一个类中不要定义过多的方法,接口应该尽量简单细化 案例 需求 假设有这样一个案例场景,现在有一个接口Repair,给定他有三个能力,可以修汽车,修火车,修飞机, 两个实现类张师傅,李师傅分别具有这些能力,有一

随机推荐