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

一、设计模式常用的七大原则

单一职责原则：一个类应该只负责一项职责

接口隔离原则：客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

依赖倒转原则

里氏替换原则

开闭原则

迪米特法则

合成复用原则

二、单一职责原则

1. 单一职责原则注意事项和细节 降低类的复杂度，一个类只负责一项职责

2.提高类的可读性，可维护性

3.降低变更引起的风险

4.通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

三、接口隔离原则

接口隔离原则注意事项和细节

segregation_origin

segregation_improve

四、依赖倒转原则

依赖倒转原则思想

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

2.抽象不应该依赖细节，细节应该依赖抽象

3.依赖倒转的中心思想是面向接口编程

4.依赖倒转原则是基于这样的设计理念：相对于细节的多边性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类

5.使用接口或抽象类的目的是指定好规范，而不涉及任何具体的操作，把展示细节的任务交给他们的实现类去完成

依赖关系传递的三种方式和应用案例

1.接口传递

2.构造方法传递

3.setter方法传递

依赖倒转原则注意事项和细节

1.低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好

2.变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序拓展和优化

3.继承时遵循里氏替换原则

五、里氏替换原则

OO中的继承性的思考和说明

1.继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏

2.继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所涉及到子类的功能可能产生故障

里氏替换原则思想

1.如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象

2.在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法

3.里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题

liskov_origin

liskov_improve依赖

liskov_improve聚合

liskov_improve组合

六、开闭原则

基本介绍

1.一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，是实现扩展细节

2.当软件需要变化时，尽量通过扩展软件实体的行为为实现变化，而不是通过修改已有的代码来实现变化

七、迪米特法则

基本介绍

1.一个对象应该对其他对象保持最少的了解

2.类与类关系越密切，耦合度越大

3.迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息

八、合成复用原则

基本介绍

原则是尽量使用合成/聚合的方式，而不是使用继承

到此这篇关于Java设计模式常用的七大原则总结的文章就介绍到这了,更多相关Java设计模式七大原则内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

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

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

  • JAVA初探设计模式的六大原则

    前言 我想用贴近生活的语句描述一下自己对六种原则的理解.也就是不做专业性的阐述,而是描述一种自己学习后的理解和感受,因为能力一般而且水平有限,也许举的例子不尽妥当,还请谅解原本我是想用JavaScript编写的,但是JavaScript到现在还没有提出接口的概念,而用TypeScript写又感觉普及度还不算特别高,所以还是决定用Java语言编写 首先要提的是:六大原则的灵魂是面向接口,以及如何合理地运用接口 P1.单一职责原则(Single Responsibility Principle) 应

  • 浅谈Java设计模式之七大设计原则

    浅谈Java设计模式之七大设计原则

    前言 学习设计模式的方法:掌握理解七大原则以及其目的,学习相应的设计模式(带着设计目的,应用场景(解决什么样的问题),如何实现(编码实现一个小例子),优缺点是什么?等等) 一.单一职责原则(SingleResponsibilityPrinciple,SRP) 定义:一个类只负责一个功能领域中的相应职责 理解:该设计模式很好理解,就是一个类只实现某个领域的相应职责,这样有利于进行调用.就比如在Java开发时,设计controller.service.manager.dao层一样的道理,进行分层分工

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

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

  • Java依赖倒转原则_动力节点Java学院整理

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. 依赖倒置原则基于这样一个事实:相对于细节的多变性,

  • java面向对象的六原则一法则小结

    1. 单一职责原则:一类只做它该做的事. 2. 里氏替换原则:子类必须能够替换基类(父类),否则不应当设计为其子类. 3. 依赖倒换原则:设计要依赖于抽象而不是具体化. 4. 接口隔离原则:接口要小而专,不能大而全. 5. 开闭原则 :一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 6. 组合/聚合复用原则:尽量使用组合和聚合,少使用继承的关系来达到复用的原则. 7. 迪米特法则:低耦合,高内聚. 以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,同时也希望多

  • 详解java设计模式之六大原则

    详解java设计模式之六大原则

    一.单一职责原则 1.单一职责定义 单一职责原则:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责 变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封

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

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

  • 高内聚低耦合原则_动力节点Java学院整理

    一.什么是耦合度 软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准.划分摸块的一个准则就是高内聚低耦合. 耦合度(Coupling)是对模块间关联程度的度量.耦合的强弱取决与模块间接口的复杂性.调用模块的方式以及通过界面传送数据的多少. 模块间的耦合度是指模块之间的依赖关系,包括控制关系.调用关系.数据传递关系.模块间联系越多,其耦合性越强,同时表明其独立性越差.降低模块间的耦合度能减少模块间的影响,防止对某一模块修改所引起的"牵一发动全身"的水波效应,保证系统设计顺利进行.

  • 浅谈java中OO的概念和设计原则(必看)

    一．OO(面向对象)的设计基础 面向对象(OO):就是基于对象概念,以对象为中心,以类和继承为构造机制,充分利用接口和多态提供灵活性,来认识.理解.刻划客观世界和设计.构建相应的软件系统.面向对象的特征:虽然各种面向对象编程语言相互有别,但都能看到它们对面向对象基本特征的支持, 即 "抽象.封装.继承.多态" : – 抽象,先不考虑细节 – 封装,隐藏内部实现 – 继承,复用现有代码 – 多态,改写对象行为 面向对象设计模式:是"好的面向对象设计",所谓"

随机推荐