设计原则

接口隔离原则: 使用多个专用的接口, 而不使用的那一的总接口, 即客户端不应该依赖那些它不需要的接口. 根据接口隔离原则, 当一个接口太大的时候, 我们需要将它分割成更小的接口, 使用该接口的客户端仅需知道与之相关的方法即可. 每个接口应该承担一种相对独立的角色, 不敢不该干的事情, 该干的事情都要干. 这里的 "接口" 有两种含义: 一种是指一个类型所具有的方法特征的集合, 仅仅是一种逻辑上的抽象; 另一种是指某种语言具体的接口定义, 有严格的定义和结构. 当把接口理解成一个类型所提供的所有方法特征的集合的时候, 这就是一种逻辑上的概念, 接口的划分将直接带来类型的划分. 可以把接口理解成角色, 一个接口只能代表一个角色, 每个角色都有他特定的接口. 也可以叫做 "角色隔离原则". 当把接口理解成狭义上的特定语言的接口, 那么ISP(Interface Segregation Principle)表达的意思是指 接口仅仅提供客户端需要的行为, 客户端不需要的行为则隐藏起来, 应当为客户端提供尽可能小的单独接口, 而不要提供大的总接口. 在很多面向对象语言中, 实现一个接口就要实现该接口中定义的所有的方法, 因此大的接口使用起来很不方便(也可以引入抽象类解决这个问题; 我觉得Objective-C语言这样就很好, 声明接口时候可以声明成可选的, 这样实现接口就不需要实现所有的接口,

开闭原则的定义 开闭原则（Open Closed Principle，OCP）由勃兰特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向对象软件构造》（Object Oriented Software Construction）中提出： 软件实体应当对扩展开放，对修改关闭 （Software entities should be open for extension，but closed for modification），这就是开闭原则的经典定义。 这里的软件实体包括以下几个部分： 项目中划分出的模块 类与接口 方法 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。 开闭原则的作用 开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。 对软件测试的影响 软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。 可以提高代码的可复用性 粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。 可以提高软件的可维护性 遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。 开闭原则的实现方法 可以通过“抽象约束、封装变化

一 概述 设计模式是针对 面向对象 设计类语言在程序设计中的一类设计思想。这些思想是前人在程序设计中总结的一些经验，它能够提高代码的 可读性、可维护性、可读性、稳健性和安全性 。到目前为止，前人共总结了23种常用的设计模式，并且这 23种设计模式 必须遵循一些设计原则，即 七大设计原则 。本文只涉及一些常用设计模式。 二 七大设计原则 1. 开闭原则 （Open-Closed Principle, OCP） 　　开闭原则表示的是类或者模块应对扩展开放，对修改关闭。 2. 单一职责原则 （Single Responsibility Principle, SRP） 3. 里氏代换原则 (Liskov Substitution Principle, LSP) 4. 依赖倒转原则 (Dependence Inversion Principle, DIP) 5. 接口隔离原则 (Interface Segregation Principle, ISP) 6. 合成复用原则 (Composite Reuse Principle, CRP) 7. 迪米特法则 (Law of Demeter, LoD) 三 常用设计模式 来源： https://www.cnblogs.com/xyzyj/p/12641768.html

[5分钟]菜鸟修研之设计模式：六大设计原则 目录 [5分钟]菜鸟修研之设计模式：六大设计原则 单一职责原则 接口隔离原则 开闭原则 里氏替换原则 依赖倒置原则 迪米特法则 笔者作为一个菜鸟，会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景。 这六种原则分别为单一职责原则、接口隔离原则、里氏替换原则、迪米特法则、依赖倒置原则、开闭原则。 单一职责原则 单一职责原则(SRP：Single responsibility principle)，规定一个类中应该只有一个原因引起类的变化。 单一职责原则的核心就是 解耦和增强内聚性 。 问题： // 假设此类是数据库上下文 public class DatabaseContext { } public class Test { private readonly DatabaseContext _context; public Test(DatabaseContext context) { _context = context; } // 用户登录 public void UserLogin() { } // 用户注销 public void UserLogout() { } // 新增一个用户 public void AddUser() { } // 修改一个用户的信息 public void UpdateUser() { }

1起源与发展 1.1梅耶开闭原则 伯特兰·梅耶一般被认为是最早提出开闭原则这一术语的人，在他1988年发行的《面向对象软件构造》中给出。这一想法认为一旦完成，一个类的实现只应该因错误而修改，新的或者改变的特性应该通过新建不同的类实现。新建的类可以通过继承的方式来重用原类的代码。衍生的子类可以或不可以拥有和原类相同的接口。 梅耶的定义提倡实现继承。具体实现可以通过继承方式来重用，但是接口规格不必如此。已存在的实现对于修改是封闭的，但是新的实现不必实现原有的接口。 1.2多态开闭原则 在20世纪90年代，开闭原则被广泛的重新定义。由于抽象化接口的使用，在这中间实现可以被改变，多种实现可以被创建，并且多态化的替换不同的实现。 相比梅耶的使用方式，多态开闭原则的定义倡导对抽象基类的继承。接口规约可以通过继承来重用，但是实现不必重用。已存在的接口对于修改是封闭的，并且新的实现必须，至少，实现那个接口。 罗伯特·C·马丁1996年发表的文章《开闭原则》是使用这种方法的启发式著作。在2001年，Craig Larman把开闭原则关联到了Alistair Cockburn的名为受护的变量的模式以及David Parnas关于信息隐藏的讨论。 2原理思想 2.1问题由来 在软件的生命周期内，因为变化，升级和维护等原因需要对软件原有代码进行修改，可能会给旧代码引入错误

依赖倒置原则的定义 依赖倒置原则的原始定义如下: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 翻译过来,包含如下三层含义: 高层模块不应该依赖低层模块,两者都应该依赖其抽象 抽象不应该依赖于细节 细节应该依赖于抽象 高层模块和低层模块容易理解,每一个逻辑的实现都是由原子逻辑组成的,不可分割的原子逻辑就是低层模块,原子逻辑的再组装就是高层模块.抽象就是指 接口或抽象类,两者都不能被实例化;细节就是实现类. 依赖倒置原则在Java语言中表现为: 模块间的依赖通过抽象产生,实现类之间不发生直接依赖,其依赖关系是通过接口或抽象类产生的 接口或抽象类不依赖于实现类 实现类依赖接口或抽象类 依赖倒置原则的好处 采用依赖倒置原则可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性. 依赖的三种写法 在开发中,对象的依赖关系有三种方式来传递 1.构造函数传递依赖对象 在类中通过构造函数声明依赖对象,这种方式叫做构造函数注入 2

1. 背景 在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。 2. 定义 一个软件实体如类、模块和函数应该对 扩展开放 ，对 修改关闭 。 3. 解决方案 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。 4. 深度理解（下面理解来源于网络） 开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。 开闭原则可能是设计模式六项原则中定义最模糊的一个了，它只告诉我们对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的告诉我们。 以前，如果有人告诉我“你进行设计的时候一定要遵守开闭原则”，我会觉的他什么都没说，但貌似又什么都说了。因为开闭原则真的太虚了。 在仔细思考以及仔细阅读很多设计模式的文章后，终于对开闭原则有了一点认识。其实，我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。 也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果前面5项原则遵守的不好，则说明开闭原则遵守的不好。 其实笔者认为

一、单一职责原则（Single Responsibility Principle） 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则（Dependence Inversion Principle，DIP） 五、接口隔离原则(Interface Segregation Principle, ISP) 六、迪米特法则(Law of Demeter, LoD) 总结 一、单一职责原则（Single Responsibility Principle） 定义：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有 可能会导致原本运行正常的职责P2功能发生故障。 单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中

Java程序员应当知道的10个面向对象设计原则 面向对象设计原则是OOPS编程的核心， 但我见过的大多数Java程序员热心于像Singleton (单例) 、 Decorator(装饰器)、Observer(观察者) 等设计模式，而没有把足够多的注意力放在学习面向对象的分析和设计上面。学习面向对象编程像“抽象”、“封装”、“多态”、“继承” 等基础知识是重要的，但同时为了创建简洁、模块化的设计，了解这些设计原则也同等重要。我经常看到不同经验水平的java程序员，他们有的不知道这些OOPS 和SOLID设计原则，有的只是不知道一个特定的设计原则会带来怎样的益处，甚至不知道在编码中如何使用这些设计原则。 (设计原则)底线是永远追求高内聚、低耦合的编码或设计。 Apache 和 Sun的开源代码是学习Java和OOPS设计原则的良好范例。它们向我们展示了，设计原则在Java编程中是如何使用的。Java JDK 使用了一些设计原则：BorderFactory类中的工厂模式、Runtime类中的单例模式、java.io 类中的装饰器模式。 虽然学习设计模式(原则)最好的方法是现实中的例子和理解违反设计原则带来的不便，本文的宗旨是向那些没有接触过或正处于学习阶段的Java程序员介绍面向对象设计原则。我个人认为OOPS 和SOLID设计原则需要有文章清楚的介绍它们，在此我一定尽力做到这点

开放封闭原则 （对扩展开放（Open for extension），对修改封闭（Closed for modification））是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所带来的巨大好处，也就是可维护、可扩展、可复用、灵活性好，开发人员应该仅对程序中频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。 接下来以一个计算器类来作为开闭原则案例： # include <iostream> using namespace std ; //开闭原则：对扩展开放，对修改关闭；增加功能时，通过增加代码实现，而不是修改源代码。 //利用面向对象编程的：继承和多态来实现开闭原则 //多态满足条件： //1、有继承关系 //2、子类重写父类中的虚函数 //多态使用： //父类指针或引用指向子类对象 //写一个抽象类，具有纯虚函数的类称为抽象类 class AbstractCaculator { public : virtual int getResult ( ) = 0 ; //纯虚函数 函数前面加上virtual关键字，变成虚函数，那么编译器在编译的时候就不能确定函数调用了。 virtual void setNum ( int a , int b ) = 0 ; } ; //加法计算器 class