设计原则

比较 设计模式 常用程度 适用层次 引入时机 结构复杂度 Abstract Factory 比较常用 应用级 设计时 比较复杂 Builder 一般 代码级 编码时 一般 Factory Method 很常用 代码级 编码时 简单 Prototype 不太常用 应用级 编码时、重构时 比较简单 Singleton 很常用 代码级、应用级 设计时、编码时 简单 Adapter 一般 代码级 重构时 一般 Bridge 一般 代码级 设计时、编码时 一般 Composite 比较常用 代码级 编码时、重构时 比较复杂 Decorator 一般 代码级 重构时 比较复杂 Facade 很常用 应用级、构架级 设计时、编码时 简单 Flyweight 不太常用 代码级、应用级 设计时 一般 Proxy 比较常用 应用级、构架级 设计时、编码时 简单 Chain of Resp. 不太常用 应用级、构架级 设计时、编码时 比较复杂 Command 比较常用 应用级 设计时、编码时 比较简单 Interpreter 不太常用 应用级 设计时 比较复杂 Iterator 一般 代码级、应用级 编码时、重构时 比较简单 Mediator 一般 应用级、构架级 编码时、重构时 一般 Memento 一般 代码级 编码时 比较简单 Observer 比较常用 应用级、构架级 设计时、编码时 比较简单

一、找出应用中可能需要变化的地方，把它们独立出来，不要和那些不需要变化的代码混在一起。 　　把会变化的部分取出并“封装”起来，好让其他部分不会受到影响。这样，代码变化引起的不经意后果变少，系统变得更有弹性。 　　下面是这个原则的另一个思考方式：“把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分”。这样的概念很简单，机会是每个设计模式背后的精神所在。所有的设计模式都提供了一套方法让“系统中得某部分改变不会影响其他部分”。 二、针对接口编程，而不是针对是吸纳编程 　　“针对接口编程”真正的意思是“针对超类型编程”。“针对接口编程”，关键就在于多态。利用多态，程序可以针对超类型编程，执行时会根据实际情况执行到真正的行为，不会被绑死在超类型的行为上。“针对超类型编程”这句话，可以更明确地说成“变量的生命类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也就意味着，声明类时不用理会以后执行时真正的对象类型。看看这个简单的多态例子：假设有一个抽象类Animal，有两个具体的实现（Dog和Cat）继承Animal。做法如下： 　　”针对实现编程“： 　　Dog d = new Dog(); 　　d.bark(); 　　但是，“针对接口/超类型编程”做法如下： 　　Animal

OCP(Open Close Principle) 开闭原则是编程中最基础、最重要的设计原则。编程中遵循其他原则，以及使用设计模式的目的就是使程序符合开闭原则。 一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。 应用示例 不满足OCP的代码 如下是一个实现画图功能的程序类图及代码 package com . atguigu . principle . ocp ; public class Ocp { public static void main ( String [ ] args ) { //使用看看存在的问题 GraphicEditor graphicEditor = new GraphicEditor ( ) ; graphicEditor . drawShape ( new Rectangle ( ) ) ; graphicEditor . drawShape ( new Circle ( ) ) ; graphicEditor . drawShape ( new Triangle ( ) ) ; } } //这是一个用于绘图的类 [使用方] class GraphicEditor { //接收Shape对象

1.定义 　　一个软件实体(如类、模块、函数)应当对扩展开放，对修改关闭。 2.定义解读 　　在项目开发的时候，都不能指望需求是确定不变化的，大部分情况下，需求是变化的。那么如何应对需求变化的情况？这就是开放-关闭原则要谈的。 　　开放-封闭原则的思想就是设计的时候，尽量让设计的类做好后就不再修改，如果有新的需求，通过新加类的方式来满足，而不去修改现有的类(代码)。那么在实际的项目开发中，是否能做到绝对的对修改关闭呢？答案一般也是否定的。既然这样，那么就要求我们在开发前，去找出变化点，然后针对变化点构造抽象，隔离出这些变化。由此可见，实现开闭原则关键是抽象。 3.优点 具有灵活性，通过拓展一个功能模块即可实现功能的扩充，不需修改内部代码。 具有稳定性，表现在基本功能类不允许被修改，使得被破坏的程度大大下降。 4.总结 　　对于设计模式的六大设计原则，单一职责原则主要说明类的职责要单一；里氏替换原则强调不要破坏继承体系；依赖倒置原则描述要面向接口编程；接口隔离原则讲解设计接口的时候要精简；迪米特法则告诉我们要降低耦合；开闭原则讲述的是对扩展开放，对修改关闭。 　　六大设计原则并没有很明显的界限，当我们在遵守某一个设计原则的时候，可能也遵守了其他的设计原则。设计原则是后面要讲述的设计模式的基础，因此在本系列讲述设计模式之前，对设计原则进行了解说。 来源： https://www

设计原则 何为设计原则？ 五大设计原则 从设计到模式 23中设计模式 何为设计？ 按照哪一种思路或者标准来实现功能 功能相同，可以有不同的设计方案来实现 随着需求增加，设计的作用才能体现出来 unix/linux设计哲学 1) 小即是美 2) 让每个程序只做好好一件事 3) 快速建立原型 4) 舍弃高效率而取可移植性 5) 采用纯文本来存储数据 6) 充分利用软件的杠杆效应（软件复用） 7) 使用shell脚本来提高效应和可移植性 8) 避免强制性的用户界面 9) 让每个程序都称为过滤器（shell的管道操作） 10) 允许用户定制环境 11) 尽量使用操作系统内核小而轻量化 12) 使用小写字母并尽量简短 13) 沉默是金（在命令行的输出有体现） 14) 各部分之和大于整体 15) 寻求90%的解决方案 SOLID五大设计原则 S - 单一职责原则 一个程序只做好一件事 如果功能过于复杂就拆分开，每个部分保持独立 O - 开放封闭原则（important） 对拓展开放，对修改封闭 增加需求时，拓展新代码，而非修改已有代码 这是软件设计的终极目标 L - 李氏置换原则 子类能够覆盖父类 父类能出现的地方子类就能出现 js中使用较少（弱类型&继承使用较少） I - 接口独立原则 +保持接口的单一独立，避免出现“胖接口” js中没有接口（typescript例外），使用较少

文章目录 1 函数设计原则 1 函数设计原则 函数设计原则1： 函数从意义上应该是一个独立的功能模块。 函数名要在一定程度上反映函数的功能。 函数参数名要能够体现参数的意义。 尽量避免在函数中使用全局变量。 函数设计原则2： 当函数参数不应该在函数体内部被修改时，应加上const声明。 如果参数是指针，且仅作输入参数，则应加上const声明。 函数设计原则3： 不能省略返回值的类型 如果函数没有返回值，那么应声明为void类型。 对参数进行有效性检查 对于指针参数的检查尤为重要。 不要返回指向“栈内存”的指针 栈内存在函数体结束时被自动释放。 函数设计原则4： 函数体的规模要小，尽量控制在80行代码之内。 相同的输入对应相同的输出，避免函数带有“记忆”功能。 避免函数有过多的参数，参数个数尽量控制在4个以内。 函数设计原则5： 有时候函数不需要返回值，但为了增加灵活性，如支持链式表达，可以附加返回值。 函数名与返回值类型在语义上不可冲突。 （getchar返回值为int类型。） 参考资料： C语言进阶剖析教程 来源： CSDN 作者： SlowIsFastLemon 链接： https://blog.csdn.net/SlowIsFastLemon/article/details/104092870

目录 设计模式之遵循原则 1. 单一职责原则(SRP) 1.1 设计目的 1.2 定义 1.3 应用 2. 开放-封闭原则(OCP) 2.1 设计目的 2.2 定义 2.3 应用 3. 依赖倒转原则 3.1 设计目的 3.2 定义 3.3 应用 4. 迪米特法则(LoD,最少知识原则) 4.1 设计目的 4.2 定义 4.3 应用 设计模式之遵循原则 1. 单一职责原则(SRP) 1.1 设计目的 我们在做编程的时候，会很自然的给一个类添加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个Form这样的类，于是我们就把各种各样的代码，像商业运算的算法，像数据库访问的SQL语句都写入到该类中，这样意味无论任何需求要来，你都需要改变这个窗体类，这样维护麻烦，无法复用，缺乏灵活性。 所以我们在设计一个类时，要遵循单一职责，让类具备原子化属性。 1.2 定义 就一个类而言，应该仅有一个引起它变化的原因。 1.3 应用 设计俄罗斯方块： 分别设计3个窗体的Form类, WallForm(背景容器), NewShapeForm(新产生的形状)， ResultShapeForm(最终组合的形状)，输入参数，横纵坐标，和形状代码。 设计Operation类，用于产生随机的NewShape的输入参数，产生改变形状的code，挪移的输入横纵坐标，获取Form的当前位置，已经最后合并操作等属性

1、单一职责原则 2、接口隔离原则 3、依赖倒转原则 接口传递 构造方法传递 setter方式传递 4、里氏替换原则 子类透明 5、开闭原则 扩展开放 修改关闭 6、迪米特法则 降低类与类之间的耦合（降低而不是消除） 最少知道原则（对自己依赖的类知道的越少越好） 成员变量、反方参数、方法返回值中的是"朋友"，局部变量不是 7、合成复用原则 尽量使用合成/聚合的方式，而不是使用继承 依赖是在方法上传递一个类（使用） 聚合是在一个类中声明另一个类，使用set方法赋值 组合是在一个类中已经实例化出来一个类 设计原则的核心思想 找出应用中可能需要变化的地方，把他们独立出来，不要和那些不需要变化的代码混在一起 针对接口编程，而不是针对实现编程 为了交互对象之间的 松耦合设计 而努力 来源： https://www.cnblogs.com/lovestart/p/11227303.html

设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？ 最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功， 软件 开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。 一个在简历中轻描淡写的“ 10 年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象 编程 、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括： · 面向对象 （ Object-Oriented ），关于面向对象没有必要重复嚼舌了，本书的第 1 章“ OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层 技术 上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。 · 面向服务 （ Service Oriented ）， SO 至少是个时髦的话题， WCF 伴着 .NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世

对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。 面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则 。面向对象设计原则也是我们用于评价一个设计模式的使用效果的重要指标之一，在设计模式的学习中，大家经常会看到诸如“XXX模式符合XXX原则”、“XXX模式违反了XXX原则”这样的语句。 最常见的7种面向对象设计原则如下表所示： 表1 7种常用的面向对象设计原则 设计原则名称 定 义 使用频率 单一职责原则 (Single Responsibility Principle, SRP) 一个类只负责一个功能领域中的相应职责 ★★★★☆ 开闭原则 (Open-Closed Principle, OCP) 软件实体应对扩展开放，而对修改关闭 ★★★★★ 里氏代换原则 (Liskov Substitution Principle, LSP) 所有引用基类对象的地方能够透明地使用其子类的对象 ★★★★★ 依赖倒转原则 (Dependence Inversion