设计模式原则
设计模式实践-zhjr04-设计原则
教 材 目 录
设计模式实践
第Ⅱ部分 敏捷设计 第七章 什么是敏捷设计 第八章 单一责任原则（SRP） 第九章 开放—封闭原则（OCP） 第十章 Liskov替换原则（LSP） 第十一章 依赖倒置原则（DIP） 第十二章 接口隔离原则（ISP）
3
第8章
设计模式实践
单一责任原则（SRP）
单一职责原则(SRP) 单一职责原则 •就一个类而言，应该仅有一个引起它变化的 就一个类而言， 就一个类而言 原因
面向对象的设计原则
设计模式实践
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设 计原则来加以避免，这些原则如下： 1. 单一职责原则(SRP) 就一个类而言，应该仅有一个引起它变化的原因。 2. 开放-封闭原则(OCP) 软件实体应该是可以扩展的，但是不可修改。 3. Liskov替换原则(LSP) 子类型必须能够替换掉它们的基类型。 4. 依赖倒置原则(DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。 5. 接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属 于它所在的类层次结构。
5
设计模式实践
规则建议 关于单一职责原则，我们的建议是： 一个类只有一个引起它变化的原因，否则就应当考虑 重构。 SRP由引起变化的原因决定，而不由功能职责决定。 虽然职责常常是引起变化的轴线，但是有时却未必， 应该审时度势。 测试驱动开发，有助于实现合理分离功能的设计。 可以通过Façade模式或Proxy模式进行职责分离。
使用了Server类，而 是使用接口IServer
class Client { IServer ci; public void GetMessage() {ci.Message();} public void Client(ClientInterface paramCi) {ci=paramCi; } }
原则切勿过度使用设计模式
原则切勿过度使用设计模式设计模式是一种软件设计中常用的指导原则和模式，它提供了一套解决问题的经验和惯例。
然而，在实际开发中，过度使用设计模式可能会导致代码的复杂性和理解难度增加，因此我们应该遵循一些原则，避免过度使用设计模式。
1. 理解需求在使用设计模式之前，我们应该充分理解项目的需求。
只有明确了问题的本质，我们才能选择合适的设计模式来解决问题。
过度使用设计模式可能导致代码冗余和不必要的复杂性。
2. 简洁可读代码的可读性是至关重要的。
过度使用设计模式可能导致代码冗长和难以理解。
因此，在使用设计模式的过程中，我们应该注重代码的简洁性和可读性，避免过度使用设计模式造成代码的复杂性增加。
3. 单一职责原则单一职责原则指的是一个类应该只有一个引起它变化的原因。
过度使用设计模式可能导致一个类承担过多的责任，违反单一职责原则。
因此，在使用设计模式的过程中，我们应该保持类的职责单一，避免过度使用设计模式导致类的复杂性增加。
4. 上下文适用性设计模式有其应用的上下文适用范围。
过度使用设计模式可能导致不必要的抽象和复杂性增加。
在使用设计模式之前，我们应该仔细考虑该设计模式是否适用于当前的项目和场景，避免盲目地使用设计模式造成代码的复杂性增加。
5. 团队共识在使用设计模式之前，应该与团队成员达成共识。
过度使用设计模式可能导致在团队之间的代码理解和协作困难。
因此，在使用设计模式的过程中，我们应该与团队进行充分的讨论和交流，避免个人过度使用设计模式导致团队协作的问题。
总之，设计模式是解决软件设计中常见问题的指导原则和模式。
但是我们应该遵循原则，避免过度使用设计模式。
在实际开发中，我们应该根据实际需求选择合适的设计模式，注重代码的简洁性和可读性，遵循单一职责原则，考虑上下文适用性，并与团队进行充分的交流和讨论。
通过合理地使用设计模式，我们可以提高代码的可维护性和可扩展性，实现高质量的软件开发。
设计模式7大原则
设计模式7大原则设计模式的7大原则是指：1. 开放-封闭原则（Open-Closed Principle，OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
即在向系统添加新的功能时，不应该修改原有的代码。
2. 单一职责原则（Single Responsibility Principle，SRP）：一个类应该只有一个引起它变化的原因。
即一个类应该只有一个职责，如果一个类承担了多个职责，就增加了它被修改的风险。
3. 里氏替换原则（Liskov Substitution Principle，LSP）：子类型必须能够替换它们的父类型。
也就是说，子类必须完全实现父类的方法，同时还可以在不违反原有功能的情况下进行扩展。
4. 依赖倒置原则（Dependency Inversion Principle，DIP）：高层模块不应该依赖于低层模块，而是应该依赖于抽象。
抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
5. 接口隔离原则（Interface Segregation Principle，ISP）：客户端不应该依赖它不需要的接口。
即一个类对另一个类的依赖应该建立在最小的接口上，而不是依赖于多个不相关的接口。
6. 迪米特法则（Law of Demeter，LoD）：一个对象应该对其他对象保持最少的了解。
即一个对象应该只与其密切的朋友进行通信，而不与非直接相关的对象进行通信。
7. 合成复用原则（Composite Reuse Principle，CRP）：尽量使用对象组合，而不是继承来达到复用的目的。
通过对象组合可以在运行时动态改变对象的行为，而继承是在编译时静态定义的。
设计模式之美（一）——设计原则、规范与重构
设计模式之美（⼀）——设计原则、规范与重构 《》是极客时间上的⼀个代码学习系列，在学习之后特在此做记录和总结。
⼀、设计原则1）SRP 单⼀职责原则（Single Responsibility Principle，SRP）是指⼀个类或者模块只负责完成⼀个职责（或者功能），模块可看作⽐类更加粗粒度的代码块，模块中包含多个类，多个类组成⼀个模块。
⼀个类包含了两个或者两个以上业务不相⼲的功能，那就说它职责不够单⼀，应该将它拆分成多个功能更加单⼀、粒度更细的类。
判断类的职责是否⾜够单⼀，需要根据具体的应⽤场景和阶段需求，例如。
（1）如果在社交产品中，⽤户的地址信息只是单纯地⽤来展⽰，那 UserInfo 可包含地址信息。
（2）如果社交产品中添加了电商模块，⽤户的地址信息还会⽤在电商物流中，那最好将地址信息从 UserInfo 中拆分出来。
由此可知，评价⼀个类的职责是否⾜够单⼀，并没有⼀个⾮常明确的、可以量化的标准。
下⾯这⼏条拆分判断原则，要更有指导意义、更具有可执⾏性： （1）类中的代码⾏数、函数或属性过多，会影响代码的可读性和可维护性，⾏数最好不超过 200 ⾏，函数个数及属性个数都最好不超过 10 个。
（2）类依赖的其他类过多，或者依赖类的其他类过多，不符合⾼内聚、低耦合的设计思想。
（3）私有⽅法过多，就要考虑能否将私有⽅法独⽴到新的类中，设置为 public ⽅法，提⾼代码的复⽤性。
（4）⽐较难给类起⼀个合适名字，很难⽤⼀个业务名词概括，这就说明类的职责定义得可能不够清晰。
（5）类中⼤量的⽅法都是集中操作类中的某⼏个属性，那就可以考虑将这⼏个属性和对应的⽅法拆分出来。
2）OCP 开闭原则（Open Closed Principle，OCP）是指添加⼀个新的功能，在已有代码基础上扩展代码（新增模块、类、⽅法等），⽽⾮修改已有代码（修改模块、类、⽅法等）。
注意，没必要纠结某个代码改动是“修改”还是“扩展”，更没必要太纠结它是否违反“开闭原则”。
设计模式七大原则
设计模式七⼤原则1. 设计模式的⽬的编写软件过程中，程序员⾯临着来⾃耦合性，内聚性以及可维护性，可扩展性，重⽤性，灵活性等多⽅⾯的挑战，设计模式是为了让程序(软件)，具有更好的 1) 代码重⽤性 (即:相同功能的代码，不⽤多次编写) 2) 可读性 (即:编程规范性, 便于其他程序员的阅读和理解) 3) 可扩展性 (即:当需要增加新的功能时，⾮常的⽅便，称为可维护) 4) 可靠性 (即:当我们增加新的功能后，对原来的功能没有影响) 5) 使程序呈现⾼内聚，低耦合的特性分享⾦句: 设计模式包含了⾯向对象的精髓，“懂了设计模式，你就懂了⾯向对象分析和设计(OOA/D)的精要” Scott Mayers 在其巨著《Effective C++》就曾经说过:C++⽼⼿和 C++新⼿的区别就是前者⼿背上有很多伤疤2. 设计模式七⼤原则设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础（即：设计模式为什么这样设计的依据）设计模式常⽤的七⼤原则有:1. 单⼀职责原则2. 接⼝隔离原则3. 依赖倒转（倒置）原则4. ⾥⽒替换原则5. 开闭原则6. 迪⽶特法则7. 合成复⽤原则3. 单⼀职责原则（SingleResponsibility）基本介绍 对类来说的，即⼀个类应该只负责⼀项职责。
如类 A 负责两个不同职责：职责 1，职责 2。
当职责 1 需求变更⽽改变 A 时，可能造成职责 2 执⾏错误，所以需要将类 A 的粒度分解为 A1，A2应⽤实例 以交通⼯具案例讲解package com.atguigu.principle.singleresponsibility;public class SingleResponsibility1 {public static void main(String[] args) {Vehicle vehicle = new Vehicle();vehicle.run("摩托车");vehicle.run("汽车");vehicle.run("飞机");}}/*** 交通⼯具类* ⽅式⼀* 1. 在⽅式⼀的 run ⽅法中，违反了单⼀职责原则* 2. 解决的⽅案⾮常的简单，根据交通⼯具运⾏⽅法不同，分解成不同类即可*/class Vehicle{public void run(String vehicle){System.out.println(vehicle + "在公路上运⾏...");}}⽅案⼀package com.atguigu.principle.singleresponsibility;public class SingleResponsibility2 {public static void main(String[] args) {RoadVehicle roadVehicle = new RoadVehicle();roadVehicle.run("摩托车");roadVehicle.run("汽车");AirVehicle airVehicle = new AirVehicle();airVehicle.run("飞机");}}/*** ⽅案⼆的分析* 1. 遵守单⼀职责原则* 2. 这样做的改动很⼤，即将类分解，同时修改客户端* 3. 改进：直接修改 Vehicle 类，改动的代码会⽐较少 => ⽅案三*/class RoadVehicle{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏");}}class AirVehicle{public void run(String vehicle){System.out.println(vehicle + "在天空运⾏");}}class WaterVehicle{public void run(String vehicle){System.out.println(vehicle + "在⽔中运⾏");}}⽅案⼆package com.atguigu.principle.singleresponsibility;public class SingleResponsibility3 {public static void main(String[] args) {Vehicle2 vehicle2 = new Vehicle2();vehicle2.run("摩托车");vehicle2.runAir("飞机");vehicle2.runWater("轮船");}}/*** ⽅式三的分析* 1. 这种修改⽅法没有对原来的类做⼤的修改，只是增加⽅法* 2. 这⾥虽然没有在类这个级别上遵守单⼀职责原则，但是在⽅法级别上，仍然是遵守单⼀职责 */class Vehicle2{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏...");}public void runAir(String vehicle){System.out.println(vehicle + "在天空运⾏...");}public void runWater(String vehicle){System.out.println(vehicle + "在⽔中运⾏...");}}⽅案三单⼀职责原则注意事项和细节1. 降低类的复杂度，⼀个类只负责⼀项职责2. 提⾼类的可读性，可维护性3. 降低变更引起的风险4. 通常情况下，我们应当遵守单⼀职责原则，只有逻辑⾜够简单，才可以在代码级违反单⼀职责原则; 只有类中⽅法数量⾜够少，可以在⽅法级别保持单⼀职责原则4. 接⼝隔离原则(Interface Segregation Principle)基本介绍 1. 客户端不应该依赖它不需要的接⼝，即⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上 2. 看图： 3. 类A通过接⼝ Interface1 依赖类B，类C通过接⼝ Interface1 依赖类D，如果接⼝ Interface1 对于类A和类C来说不是最⼩接⼝，那么类B 和类 D 必须去实现他们不需要的⽅法。
设计模式六大规则
设计模式六⼤规则1.单⼀职责原则（六⼤规则中的⼩萝莉，⼈见⼈爱）：描述的意思是每个类都只负责单⼀的功能，切不可太多，并且⼀个类应当尽量的把⼀个功能做到极致。
2.⾥⽒替换原则（六⼤原则中最⽂静的姑娘，但却不太招⼈喜欢）：这个原则表达的意思是⼀个⼦类应该可以替换掉⽗类并且可以正常⼯作。
3. 接⼝隔离原则（六⼤原则当中最挑三拣四的挑剔⼥，胸部极⼩）：也称接⼝最⼩化原则，强调的是⼀个接⼝拥有的⾏为应该尽可能的⼩。
4.依赖倒置原则（六⼤原则中最⼩鸟依⼈的姑娘，对抽象的东西⾮常依赖）：这个原则描述的是⾼层模块不该依赖于低层模块，⼆者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
5.迪⽶特原则（六⼤原则中最害羞的姑娘，不太爱和陌⽣⼈说话）：也称最⼩知道原则，即⼀个类应该尽量不要知道其他类太多的东西，不要和陌⽣的类有太多接触。
6.开-闭原则（六⼤原则中绝对的⼤姐⼤，另外五姐妹⼼⽢情愿⾂服）：最后⼀个原则，⼀句话，对修改关闭，对扩展开放。
《简介》说到设计模式，当初第⼀次听到时，第⼀反应就是很深奥，完全理解不了这个概念到底是什么意思，下⾯我先从⽹上摘录⼀份定义。
设计模式（Designpattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。
上⾯是百度当中的解释，来解释⼀下这句简单的话的含义，⼏个关键词。
反复使⽤：这个不⽤过多解释，设计模式被使⽤太多了，上个系列spring源码当中就出现了很多模式，记忆中⽐较深刻的有模板模式，代理模式，单例模式，⼯⼚模式等等。
多数⼈知晓：这个就不需要过多解释了。
分类编⽬：就是说可以找到⼀些特征去划分这些设计模式，从⽽进⾏分类。
代码设计经验：这句很重要，设计经验的总结，也就是说设计模式，是为了指导设计⽽从经验中总结出来的套路。
还有⼀种说法是说，设计模式是可以解决特定场景的问题的⼀系列⽅法，其实我觉得这个解释更贴切⼀点。
《为何学习设计模式》上⾯简单的介绍，是让各位⾸先搞清楚设计模式是什么，下⾯我们来说说为什么要学习设计模式，学习总要有个驱动⼒。
设计模式七大原则
设计模式七大原则
设计模式是软件开发中最重要的技术之一，它能够为软件开发者提供一个可复用的解决方案，以解决软件开发中的常见问题。
设计模式的七个原则是：开放-封闭原则、单一职责原则、接口隔离原则、依赖倒转原则、迪米特法则、里氏替换原则和合成复用原则。
首先，开放-封闭原则规定，一个软件实体应该是可扩展的，但是不可修改。
这意味着软件应该可以扩展功能，但不能改变原有的代码，以保证软件的可维护性和可扩展性。
其次，单一职责原则要求每个模块或类都应该只有一个职责。
这样，每个模块就有一组明确的职责，意味着软件更易于维护和扩展，也更容易使用。
第三，接口隔离原则是指客户端不应该依赖它不需要的接口，即一个接口应该尽可能小，这样它才能更容易被使用。
第四，依赖倒转原则是指高层模块不应该依赖低层模块，两者都应该依赖其抽象，这样，当高层模块发生变化时，低层模块不会发生变化。
第五，迪米特法则是指一个对象应该尽可能少地与其他对象发生相互作用，只和朋友交流，而不和陌生人说话。
第六，里氏替换原则是指子类可以替换其父类，程序中使用父类的地方也可以使用子类，这样可以提高程序的灵活性和可扩展性。
最后，合成复用原则是指尽量使用对象的合成/聚合的方式，而不是使用继承。
这样可以使程序更加灵活，并且能够更容易地复用代码。
总之，设计模式的七个原则是软件开发中一个重要的概念，它们能够为软件开发者提供一些可复用的解决方案，以解决软件开发中的常见问题。
正是由于它们的正确使用，软件开发能够取得很大的成功。
设计模式六大原则
设计模式六大原则设计原则是基本的工具,应用这些规则可以使你的代码更加灵活、更容易维护,更容易扩展。
今天店铺分享了设计模式六大原则，一起来了解吧。
设计模式六大原则设计模式原则1：单一职责原则定义：不要存在多于一个导致类变更的原因。
通俗的说，即一个类只负责一项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。
当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。
分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。
这样，当修改类T1时，不会使职责P2发生故障风险;同理，当修改T2时，也不会使职责P1发生故障风险。
说到单一职责原则，很多人都会不屑一顾。
因为它太简单了。
稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。
在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。
而避免出现这一问题的方法便是遵循单一职责原则。
虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。
为什么会出现这种现象呢?因为有职责扩散。
所谓职责扩散，就是因为某种原因，职责P 被分化为粒度更细的职责P1和P2。
比如：类T只负责一个职责P，这样设计是符合单一职责原则的。
后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。
但是在程序已经写好的情况下，这样做简直太费时间了。
所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。
(这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
设计模式原则开闭原则
对扩展开放，对修改关闭
里氏替换原则
任何基类可以出现的地方，子类一定可以出现
是对开-闭原则的补充
依赖倒转原则
开闭原则的基础
面向接口编程，依赖于抽象而不依赖具体
接口隔离原则
降低依赖，降低耦合
使用多个隔离的接口，比使用单个接口要好
迪米特原则
迪米特原则_百度百科
一个对象应当对其他对象尽可能少的了解
例子
门面模式(Facade) 中介模式(Mediator)
设计体现
优先考虑将一个类设置成不变类
尽量降低一个类的访问权限
谨慎使用Serializable
尽量降低成员的访问权限
合成复用原则
尽量使用合成/聚合的方式，而不是使用继承。