设计原则

什么是最少知识原则？ 最少知识原则（LKP）说的是一个软件实体应当尽可能少地与其他实体发生相互作用。这里的软件实体是一个广义的概念，不仅包括对象，还包括系统、类、模块、函数、变量等。本节我们主要针对对象来说明这个原则，下面引用《面向对象设计原理与模式》一书中的例子来解释最少知识原则： 某军队中的将军需要挖掘一些散兵坑。下面是完成任务的一种方式：将军可以通知上校让他叫来少校，然后让少校找来上尉，并让上尉通知一个军士，最后军士唤来一个士兵，然后命令士兵挖掘一些散兵坑。 这种方式十分荒谬，不是吗？不过，我们还是先来看一下这个过程的等价代码： gerneral.getColonel( c ).getMajor( m ).getCaptain( c ) .getSergeant( s ).getPrivate( p) 让代码通过这么长的消息链才能完成一个任务，这就像让将军通过那么多繁琐的步骤才能命令别人挖掘散兵坑一样荒谬！而且，这条链中任何一个对象的改动都会影响整条链的结果。 减少对象之间的联系 单一职责原则指导我们把对象划分成较小的粒度，这可以提高对象的可复用性。但越来越多的对象之间可能会产生错综复杂的联系，如果修改了其中一个对象，很可能会影响到跟它相互引用的其他对象。对象和对象耦合在一起，有可能会降低它们的可复用性。在程序中，对象的“朋友”太多并不是一件好事，“城门失火，殃及池鱼”和

设计模式之路 | 目录 设计模式之路 | GoF 的 23 种设计模式的分类和功能 设计模式之路 | 软件设计模式概述 设计模式之路 | 面向对象设计原则 —— 单一职责原则 设计模式之路 | 面向对象设计原则 —— 接口隔离原则 设计模式之路 | 面向对象设计原则 —— 依赖倒置原则 设计模式之路 | 面向对象设计原则 —— 开闭原则 设计模式之路 | 面向对象设计原则 —— 迪米特法则 设计模式之路 | 面向对象设计原则 —— 合成复用原则 设计模式之路 | 单例模式 设计模式之路 | 工厂方法 设计模式之路 | 抽象工厂 设计模式之路 | 原型模式 设计模式之路 | 建造者模式 设计模式之路 | 适配器模式 来源： CSDN 作者： 写代码的小森森 链接： https://blog.csdn.net/Willson_L/article/details/103383239

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 六大设计原则 开闭原则 简述：对修改关闭，对扩展开放 解读：需求变更时，尽量不要修改已有的代码。 单一职责原则 简述：一个类不应承担过多的职责，或者说，就一个类而言，应该只有一个引起它变化的原因 解读：一个类不能承担过多的功能，只专心一件事，并把这件事做好。 优点： 降低类的复杂度 提高类的可读性 降低变更引起的风险 小结：变更是必然的，如果单一职责遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。 里氏替换原则 （继承关系） 简述：所有引用父类（基类）的地方，必须能透明地使用其子类的对象。 解读：继承关系中，能用父类的地方，那么其任何子类也可以被正常调用，所以子类尽量不要修改父类的方法 依赖倒转原则 （接口编程） 简述：抽象不应该依赖于细节，细节当依赖于抽象。换言之，要针对接口编程，而非针对实现编程。 解读：上述中抽象可简单理解为接口，细节就是接口的实现类。通过抽象或接口实现类与类之间的依赖关系 接口隔离 （接口隔离） 简述：使用多个专门的接口，不使用单一的总接口。建立单一接口，不要建立庞大/臃肿的接口。 解读：定义一个接口时不要定义的大而广，而是把他们分割成一些更细小的接口。一般 不满足单一职责原则都不满足接口隔离原则 。 小结：接口隔离原则核心思想就是细化接口，提高程序的灵活性。接口不能太小

基本概念 单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。 There should never be more than one reason for a class to change. 实例说明 简单栗子感受一哈 看如下类图 分析一下这个类图哈，UserInfo实现IUserInfo接口，IUserInfo接口下有一系列方法，不过认真看一下这些方法，结合让你直接定义一个UserInfo类，很容易会发现username、password、userID会被我们作为类的属性，其他的会被作为类的行为。这样设计接口就不满足原则了。 可拆分为以下类图 分析一哈这个类图，仅将原来的一个接口泛化，即IUserInfo接口继承了两个接口，…………这些仅起到说明的作用，其他和上述类图类似，不详细说明了。 在看以下这个类图，多了一个依赖关系，这种设计就符合单一职责原则 以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一 职责原则呢？单一职责原则的定义是： 应该有且仅有一个原因引起类的变更。 复杂栗子感受一哈 分析一下这个类图哈，定义了一个电话的接口，有打电话、通话、挂断这三个方法，正常我们开发可能就写成这样子了，但是我阅读的这书中，却提出了这里面包含了协议管理和处理数据两个职责，分别对应打电话、挂断电话和通话，细想一下

单一职责原则： 一个对象应该只包含单一的职责，并且该职责被完整的封装到一个类中 开闭原则： 软件实体应当对扩展开放，对修改关闭 里氏代换原则： 所有引用基类的地方必须能透明的使用其子类的对象 依赖倒转原则： 高层模块不应该依赖底层模块，它们都应该依赖抽象，抽象不应该依赖于细节，细节应该依赖于抽象 接口隔离原则： 客户端不应该依赖那些它不需要的接口 合成复用原则： 优先使用对象组合，而不是通过继承来达到复用的目的 迪米特法则： 每一个软件单位对其它单位都只有最少的知识，而且局限于那些于本单位密切相关的软件单位 设计原则包括设计模式，重在理解，下面是我觉的写的不错的一篇关于设计原则的博客： 面向对象设计原则详解 来源： https://www.cnblogs.com/chunyun/p/11982403.html

一、OO设计基础 1、封装 2、继承 3、多态 4、抽象 二、OO设计原则 1、找出应用中需要变化之处，让它们独立出来，不要和那些不需要变化的代码混在一处。 2、针对接口编程，而不是针对实现编程。 针对接口编程，即“针对超类型编程”。针对接口编程，关键就在于多态。利用多态，程序可以针对超类型编程，不会被绑死在超类型的行为上。 示例：有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。 针对实现编程： Dog d = new Dog(); d.bark(); 针对接口/超类型编程： Animal a = new Dog(); a.makeSound(); 更进一步，子类实例化的动作不再需要在代码中硬编码，而是在运行时才指定具体的对象： a = getAnimal(); a.makeSound(); 3、多用组合，少用继承。 4、为了交互对象之间的松耦合设计而努力。 5、开放－关闭原则：类应该对扩展开放，对修改关闭。 应用该原则时，应该把注意力集中在设计中最有可能改变的地方，然后应用开放－关闭原则。 6、依赖倒置原则 要依赖抽象，不要依赖具体类。 这个原则看上去很像“针对接口编程，而不是针对实现编程”，然而这里更强调抽象。这个原则说明了：不能让高层组件依赖低层组件，而且不管是高层还是低层组件，两者都应该依赖于抽象。所谓“高层”组件

1.开放原则 开闭原则（Open-Closed Principle,OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增加新功能。在现实生活中对于开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间，规定每天工作8小时。意思就是说，对于每天工作8小时这个规定是关闭的，但是你什么时候来，什么时候走是开放的。早来早走，晚来晚走。 实现开闭原则的核心思想就是面向抽象编程，接下来我们来看一下关于课程的代码。首先创建一个课程接口 ICourse： public interface ICourse { Integer getId ( ) ; String getName ( ) ; Double getPrice ( ) ; } 整个课程生态有 Java 架构、大数据、人工智能、前端、软件测试等，我们来创建一个 Java架构课程的类 JavaCourse： public class JavaCourse implements ICourse { private Integer Id ; private String

面向对象的基本设计原则(SOLID) 1.单一职能原则(SRP-Single responsibility principle) 描述 一个类、接口或方法只负责一项职责(只有一个改变的原因) 优点 可以降低类的复杂度、类之间的耦合度 便于扩展、复用和维护，提高代码可读性 降低变更引起的风险 应用 Entity、Biz、Dao、Control 说明 1.一般通过多接口(Interface)的形式进行职能划分2.要注意职能扩散 2.开放-封闭原则(OCP-Open Closed Principle) 描述 类、模块等对于扩展是开放的(Open for extension) 对于修改是封闭的(Closed for modification) Software entities like classes,modules and functions should be open for extension but closed for modifications. 分类 梅耶开闭原则(类的继承) 多态开闭原则(抽象化接口实现) 优点 增强系统的稳定性、可扩展性、可维护性 提高代码的复用性 说明 1.通过接口和抽象类对扩展进行约束 2.引用对象、参数类型尽量使用接口或抽象类 3.接口或抽象类尽量不修改(可通过增加新的接口或抽象类完成扩展) 4.使用元数据控制模块(例如Spring的控制反转)

七大设计原则 单一职责原则： 尽可能的功能细分（类细分，方法细分）：如一个类由于某变量而细分方法，该细分方法再细分，需要重构（最好细分类） 接口隔离原则：（C类实现A接口全部方法，而D，B类依赖于A接口中的某方法（依赖的方法不一样））：将A接口分成多个接口 依赖倒置原则： 里氏替换原则： 开闭原则： 迪米特法则 合成复用原则 来源： https://www.cnblogs.com/wen-/p/11993458.html

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据 7 条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。我们将在下面的几节中依次来介绍这 7 条原则，本节首先介绍开闭原则。 开闭原则的定义 开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出： 软件实体应当对扩展开放，对修改关闭（Software entities should be open for extension，but closed for modification） ，这就是开闭原则的经典定义。 这里的软件实体包括以下几个部分： 项目中划分出的模块 类与接口 方法 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。 开闭原则的作用 开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。 1. 对软件测试的影响 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。 2.