软件设计原则

S.O.L.I.D 能帮助我们成为更优秀的开发人员。 S.O.L.I.D 是面向对象设计（OOD）的头五大基本原则的首字母缩写，由俗称「 鲍勃大叔 」的 Robert C. Martin 提出。 这些原则，结合在一起能够方便程序员开发易于维护和扩展的软件，也让开发人员轻松避免代码异味，易于重构代码，也是敏捷或自适应软件开发的一部分。 面向对象的五大原则： 单一职责原则SRP：Single Responsibility Principle 开放封闭原则OCP：Open－Close Principle Liskov替换原则LSP：Liskov Substitution Principle 依赖倒置原则DIP：Dependency Invertion Principle 接口隔离原则ISP：Interface Separate Principle 在面向对象设计中，如何通过很小的设计改变就可以应对设计需求的变化，这是令设计者极为关注的问题。为此不少OO先驱提出了很多有关面向对象的设计原则用于指导OO的设计和开发。下面是几条与类设计相关的设计原则。 1. 单一职责（the Single Responsibility Principle SRP） 系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。 每一个职责都是一个设计的变因，需求变化的时候

一、面向对象应用程序开发原则（ SOLID ） 1 单一职责原则（ SRP ） 定义： 一个类应该只有一个发生变化的原因。这条原则曾被称为内聚性，即一个模块的组成元素之间的功能相关性。 为什么要遵守这条原则？ 如果一个类承担的职责过多，就等于把这些职责耦合到了一起。一个职责的变化可能削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。 运用与辨析 例 1 ：记录日志 public class Logger { public void LogToFile<T>(T msg); public void LogToDB<T>(T msg); public void LogToWindows<T>(T msg); } 这个例子定义了一个日志类，包含三种方法：将日志写入本地文件、数据库或 windows 系统日志。一般会人为日志类记录日志这个动作算做一个职责，然而事实并非如此，将日志记录到不同的存储介质算作不同的职责。基于这种认识，断定这个类包含了太多的职责，应该将职责分离出来。 例 2 ：一个大的业务层类 一个用户履历操作相关的类，包括：用户的教育背景，社会兼职职务，工作经历个人简历，获得的荣誉等，示例如下： public class UserResumeService { #region 社会兼职 //添加社会兼职 public

单一职责原则：类的职责尽可能单一，不同的职责尽可能放在不同类中 开闭原则：软件实体对扩展开放，对修改关闭 里氏代换原则：可以接受基类的地方必然可以接受子类 依赖倒转原则：针对抽象层编程，不针对具体类编程 接口隔离原则：用多个专门的接口取代一个统一的接口 合成复用原则：系统中尽可能使用组合和聚合关系，尽量不使用继承关系 迪米特法则：一个实体对其他实体的引用越少越好。两个实体不直接彼此通信尽量通过第三者传递信息 来源： CSDN 作者： GodGump 链接： https://blog.csdn.net/GodGump/article/details/104491568

1.避免重复原则（DRY – Don’t repeat yourself） 编程的最基本原则是避免重复。在程序代码中总会有很多结构体，如循环、函数、类等等。一旦你重复某个语句或概念，就会很容易形成一个抽象体。 2.抽象原则（Abstraction Principle ） 与DRY原则相关。要记住，程序代码中每一个重要的功能，只能出现在源代码的一个位置。 3.简单原则（Keep It Simple and Stupid ） 简单是软件设计的目标，简单的代码占用时间少，漏洞少，并且易于修改。 4.避免创建你不要的代码 Avoid Creating a YAGNI (You aren’t going to need it) 除非你需要它，否则别创建新功能。 5.尽可能做可运行的最简单的事（Do the simplest thing that could possibly work） 尽可能做可运行的最简单的事。在编程中，一定要保持简单原则。作为一名程序员不断的反思“如何在工作中做到简化呢？”这将有助于在设计中保持简单的路径。 6.别让我思考(Don’t make me think ) 这是Steve Krug一本书的标题，同时也和编程有关。所编写的代码一定要易于读易于理解，这样别人才会欣赏，也能够给你提出合理化的建议。相反，若是繁杂难解的程序，其他人总是会避而远之的。 7.开闭原则

UML 基本介绍 UML——Unified modeling language UML (统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果。 UML 本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如 类、接口、实现、泛化、依赖、组合、聚合 等。 各种关系的符号表示： 类图—依赖关系（Dependence） 用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系。 类之间的关系： 依赖、泛化（继承）、实现、关联、聚合与组合 。 依赖： 只要是在类中用到了对方，那么他们之间就存在依赖关系。如果没有对方，连编绎都通过不了。 public class PersonServiceBean { private PersonDao personDao ; //类 public void save ( Person person ) { } public IDCard getIDCard ( Integer personid ) { } public void modify ( ) { Department department = new Department ( ) ; } } public class PersonDao { } public class IDCard

1.避免重复原则（DRY – Don’t repeat yourself） 编程的最基本原则是避免重复。在程序代码中总会有很多结构体，如循环、函数、类等等。一旦你重复某个语句或概念，就会很容易形成一个抽象体。 2.抽象原则（Abstraction Principle ） 与DRY原则相关。要记住，程序代码中每一个重要的功能，只能出现在源代码的一个位置。 3.简单原则（Keep It Simple and Stupid ） 简单是软件设计的目标，简单的代码占用时间少，漏洞少，并且易于修改。 4.避免创建你不要的代码 Avoid Creating a YAGNI (You aren’t going to need it) 除非你需要它，否则别创建新功能。 5.尽可能做可运行的最简单的事（Do the simplest thing that could possibly work） 尽可能做可运行的最简单的事。在编程中，一定要保持简单原则。作为一名程序员不断的反思“如何在工作中做到简化呢？”这将有助于在设计中保持简单的路径。 6.别让我思考(Don’t make me think ) 这是Steve Krug一本书的标题，同时也和编程有关。所编写的代码一定要易于读易于理解，这样别人才会欣赏，也能够给你提出合理化的建议。相反，若是繁杂难解的程序，其他人总是会避而远之的。 7.开闭原则

片头 在上一篇文章中已经介绍了“单一职责原则”在单片机程序中的使用，并以“环形缓存”作为介绍切入点，因为“环形缓存”在应用中比较多，所以在介绍“开闭原则”时依然以它作为介绍切入点。 六个设计原则分别是：A、单一职责原则；B、开闭原则；C、里氏替换原则；D、最少知识原则；E、接口隔离原则；F、依赖倒置原则；G、激活原则； 以上有7个，最后一个是我加上去的，此文主要介绍第二个设计原则：开闭原则在设计STM32单片机软件的应用。 正文 定义：开闭原则表示打开拓展的大门，关闭修改的大门。 要做的“开闭原则”首要任意就是解决（确定）范围，即开闭原则的软件单位。那么在单片机软件开发中的职责单一的软件单位是什么呢？是一个函数，一个结构体，一个枚举定义，一个软件模块（XXX.c与XXX.h）。 首先以一个电路图说明“开闭原则”的例子（在此假设读者具备一定原理图知识）背景假设：此图是一个智能锁的原理图，目前此图版本：V7.0。如下图所示： 由于市场需求需要增加人体识别PIR传感器,需要对V7.0版原理图 “更新”。现在有以下两种更新方案，如下图所示： 以上两种方案，一个调整了原来的信号定义，一个不改变原来信号定义。哪个方案优哪种方案劣？从版本后看：现在到了8.0版，可见之前有很多个版本，需要考虑的情况很多。假设现在V8.0版已经是这个“智能锁”产品的第10个年头了。之前V1.0还有库存吗

设计模式是为了让程序具有更好的 1、代码重用，不多次编写 2、可读性：编码规范，便于阅读与理解 3、可扩展性：易于增加新的功能 4、可靠性：增加新功能，对原来的功能没有影响 5、高内聚，低耦合 一、单一职责原则 应该有且只有一个原因引起类的变更。 即一个类或者接口的职责应该单一(业务逻辑层面) 最佳实践 1、接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化 二、里氏替换原则 有2种定义 1、如果对每个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都替换为o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型 2、所有引用基类的地方必须能够透明地使用其子类的对象 通俗地将，就是只要父类能出现的地方，子类都可以出现，而且替换为子类对象也不会产生任何错误或异常 最佳实践 1、项目中采用里氏替换原则，尽量避免子类的“个性”，即子类独特的属性和方法 三、依赖倒置原则 包含三层含义： 1、高层模块不应该依赖低层模块，两者都应该依赖其抽象 2、抽象不应该依赖细节 3、细节应该依赖抽象 在Java中，抽象指的是接口或者抽象类，两者都是不能被实例化的，细节就是实现类，实现接口或者继承抽象类产生的类就是细节，可以被实例化。 所以上面三层含义可以理解为 1、模块之间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或者抽象类产生

迪米特法则的定义 迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。 迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。 迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。 迪米特法则的优点 迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。 降低了类之间的耦合度，提高了模块的相对独立性。 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。 但是

java6大设计原则 1、单一职责原则 一个类只负责一项职责，如果类A负责两个不同的职责1和2，如果职责1需要更改时，可能会造成职责2执行错误，所以将A的粒度分为A1和A2。（某些情况下可以不用在类的级别上做到单一职责原则，至少在类方法上做到单一职责原则） 优点： 1、降低类的复杂度； 2、提高类的可读性和可维护性； 3、降低因变更引起的风险； 4、当类中方法数量足够少时，逻辑较简单时可以在方法级别上保持单一原则。 2、接口隔离原则 一个类对一个接口的依赖应该建立在最小接口上（所继承的接口中的全部方法都是这个类所需要的），否则就会实现他不需要的方法。 3、依赖倒转原则 高层模块不应该依赖低层模块，抽象不应该依赖细节，其中心思想就是面向接口编程，一般来说抽象的东西较为稳定，使用抽象类或接口制定好规范，细节的内容交给具体的实现类完成。 4、里氏替换原则 在继承时，尽量不要 在子类中重写父类方法，易造成方法功能混乱，需保持方法的的一致性，但可以重载。通用的做法是原来的父类和子类都继承一个更基本的类，去掉继承关系，采用依赖，聚合，组合等方式代替。 5、开闭原则 一个软件如类，模块或函数对提供方扩展开放，对使用方修改关闭，当软件需求变化时，尽量通过扩展软件实体的行为来实现而不是通过已有的代码来实现。 6、迪米特原则（最少知道原则） 一个对象应该对其他对象保持最少的了解，降低类与类之间的耦合性