设计原则

单一职责原则（ Single Responsibility Principle ） 定义： 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来： 类 T 负责两个不同的职责：职责 P1 ，职责 P2 。当由于职责 P1 需求发生改变而需要修改类 T 时，有可能会导致原本运行正常的职责 P2 功能发生故障。 解决方案： 遵循单一职责原则。分别建立两个类 T1 、 T2 ，使 T1 完成职责 P1 功能， T2 完成职责 P2 功能。这样，当修改类 T1 时，不会使职责 P2 发生故障风险；同理，当修改 T2 时，也不会使职责 P1 发生故障风险。 说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。 所谓职责扩散，就是因为某种原因，职责 P 被分化为粒度更细的职责 P1 和 P2 。 比如：类 T 只负责一个职责 P ，这样设计是符合单一职责原则的。后来由于某种原因

设计模式的六大设计原则 开闭原则（O） ：对扩展开放，对修改关闭。开闭原则是总原则，指尽量高度抽象，易扩展。 单一原则（S） ：一个类的接口抽象一个职责。 里氏替换原测（L） ：里氏替换是对开闭原则的补充，开闭原则为接口抽象，里氏替换则为接口的具体实现。 依赖倒置原则（D） ：面向接口编程，不跟具体实现类交互，跟接口交互。 接口隔离原则（I） ：每个接口的实现类必须是完全实现，如果说子类中存在不需要实现的方法，那么接口应该把这个方法拆分出去。 迪米特法则（D） ：一个类对自己的依赖应该是知道的越少越好，只需要关注调用的public方法。 23种Java设计模式 来源： https://blog.csdn.net/weixin_39506910/article/details/99451389

1、里氏替换原则来源 继承优点： 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性； 提高代码的重用性； 子类可以形似父类，但又易于父类； 提高代码的可扩展性，实现父类的方法就可以“为所欲为”了； 提高产品或者项目的开放性； 继承缺点： 继承是侵入性的，只要是继承，就必须拥有父类的所有属性和方法； 降低代码灵活性，子类必须拥有父类的属性和方法，子类在自由世界中多了些约束； 增强了耦合性，当父类的常量，变量或者方法被修改时，需要考虑子类的修改 Java用extends关键字来实现继承，它采用了单一继承的规则，而C++则采用了多重继承的规则，一个子类可以继承多个父类。从总体上看，单继承利大于弊。如何把“利”发挥最大作用，同时减少“弊”带来的问题。解决方案就是引入里氏替换原则（LSP）。 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为 没有 发生变化，那么类型S是类型T的子类型。 所有引用基类的地方必须能透明地使用其子类的对象。 对上面第二种解释为“只要父类能出现的地方，子类都可以出现，而且替换为子类也不会产生任何错误或者异常，使用者不需要知道是父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必就能适应。” 2、里氏替换原则规则 a)、子类必须完全实现父类的方法 我们先定义一个枪的接口

开闭原则（Open Closed Principle）是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。 定义： 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 Softeware entities like classes,modules and functions should be open for extension but closed for modifications. 开闭原则的含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现变化。 软件实体包括以下几个部分： 项目或软件产品中按照一定的逻辑规则划分的模块 抽象和类 方法 开闭原则是为软件实体的未来事物而制定的对现行开发设计进行约束的一个原则。 注意：开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段了。 变化的类型： 逻辑变化 子模块变化 可见试图变化 一个项目的基本路径应该是这样的：项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码修改，保持历史代码的纯洁性，提高系统的稳定性。 开闭原则的重要性： 开闭原则对测试的影响 开闭原则可是保持原有的测试代码仍然能够正常运行，我们只需要对扩展的代码进行测试就可以了。

1、顺口溜： 开里和依单迪 合成聚合复用 面向对象中的五大设计原则： solid: srp ocp lod isp dip srp: Single responsibility principle ocp: Open Closed Principle lod: Law of Demeter isp: Interface-Segregation Principle dip: Dependence Inversion Principle 2、开闭原则(OCP)： 开放封闭原则（OCP，Open Closed Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。 关于开放封闭原则，其核心的思想是： 软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。 因此，开放封闭原则主要体现在两个方面： 对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。 对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。 3、里氏替换原则(LSP)： 父类可以由子类替换 里氏替换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏替换原则中说，任何基类可以出现的地方，子类一定可以出现。

面向对象设计原则是 OOPS（Object-Oriented Programming System，面向对象的程序设计系统）编程的核心，但大多数 Java 程序员 追逐像 Singleton、Decorator、Observer 这样的 设计模式 ，而不重视面向对象的分析和设计。甚至还有经验丰富的 Java 程序员没有听说过 OOPS 和 SOLID设计原则，他们根本不知道设计原则的好处，也不知道如何依照这些原则来进行编程。 众所周知，Java 编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。查看 Apache 和 Sun 的开放源代码能帮助你发现其他 Java 设计原则在这些代码中的实际运用。Java Development Kit 则遵循以下模式：BorderFactory 类中的工厂模式、Runtime 类中的单件模式。你可以通过 Joshua Bloch 的 《 Effective Java 》 一书来了解更多信息。我个人偏向的另一种面向对象的设计模式是 Kathy Sierra 的 《 Head First设计模式 》 以及 《 Head First Object Oriented Analysis and Design 》 。 虽然实际案例是学习设计原则或模式的最佳途径，但通过本文的介绍，没有接触过这些原则或还在学习阶段的 Java 程序员也能够了解这

微服务设计原则 AKF拆分原则 Y轴（功能） X轴（水平扩展） Z轴（数据分区） 前后端分离 无状态服务 RestFul通信风格（无状态通信原则） AKF拆分原则 AKF扩展立方体是由一个叫AKF公司的技术专家总结出的应用扩展的三个维度。理论上安装这三个维度扩展，可以把一个单体系统进行无线扩展。 Y轴（功能） 按照功能拆分，基于不同的业务拆分。 X轴（水平扩展） 将微服务运行多个实例，做成集群加负载均衡的模式。 Z轴（数据分区） 基于类似的数据分区。例如互联网打车突然火了。用户量激增，集群模式撑不住了，那就可以按照用户请求的地区进行数据分区，建成北京、上海等多个集群。 前后端分离 前后端分离，不仅要做到技术代码的分离，还要做到物理分离的部署方式，不要使用之前的服务端模板技术，如JSP。 分离模式下，前后端交互界面更清晰，就剩下接口和模型，后端的接口简洁明了，更容易维护。 前端多渠道应用场景更容易实现，后端无需变更，采用统一的数据和模型，即可支撑PC前端、移动APP等访问。 无状态服务 状态：如果有一个数据被多个服务共享，则这个数据就是状态。 有状态服务：依赖于状态数据的服务。 无状态服务：不依赖状态数据的服务。 这里提到的无状态服务原则，并不是说在微服务中不允许存在状态，而是将有状态的业务服务改为无状态的计算服务，把“状态”数据迁移到对应的“有状态服务”中。 例如

1. 原始单据与实体之间的关系 　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。 在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。 　　　　　　 这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 　　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键 　　(因为它无子孙), 但必须要有外键(因为它有父亲)。 　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专 　　家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核 　　心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 　　基本表与中间表、临时表不同，因为它具有如下四个特性： 　　 (1) 原子性。基本表中的字段是不可再分解的。 　　 (2) 原始性。基本表中的记录是原始数据（基础数据

面向对象设计原则是OOPS编程的核心， 但我见过的大多数Java程序员热心于像Singleton (单例) 、 Decorator(装饰器)、Observer(观察者) 等设计模式，而没有把足够多的注意力放在学习面向对象的分析和设计上面。学习面向对象编程像“抽象”、“封装”、“多态”、“继承” 等基础知识是重要的，但同时为了创建简洁、模块化的设计，了解这些设计原则也同等重要。我经常看到不同经验水平的java程序员，他们有的不知道这些OOPS 和SOLID设计原则，有的只是不知道一个特定的设计原则会带来怎样的益处，甚至不知道在编码中如何使用这些设计原则。 (设计原则)底线是永远追求高内聚、低耦合的编码或设计。 Apache 和 Sun的开源代码是学习Java和OOPS设计原则的良好范例。它们向我们展示了，设计原则在Java编程中是如何使用的。Java JDK 使用了一些设计原则：BorderFactory类中的工厂模式、Runtime类中的单例模式、java.io 类中的装饰器模式。顺便说一句，如果您真的对Java编码原则感兴趣，请阅读Joshua Bloch 的Effective Java，他编写过Java API。我个人最喜欢的关于面向对象设计模式的是Kathy Sierra的Head First Design Pattern(深入浅出设计模式)

1.restFul 架构 一个应用架构遵循rest设计原则 设计风格 称之为restFul架构 2.rest设计原则 1.rest:资源表现层状态转化 资源：网络中一切实际存在的事务 如 一条记录 表现层： 资源具体呈现出来形式 表现层 状态转化： 通过client 操作服务上资源使资源发生状态改变，状态的改变无非对应资源（增删改查） 2.设计原则 1.一切网络中实际存在事务都有一个唯一url 传统url: http://localhost:8989/项目名/user/find?id=21 resturl: http://localhost:8989/项目名/user/find/21/ 2.对资源操作无非是增删改查（CRUD）client对应服务器端四种操作提出额外四个HTTP动词 GET 查询 POST 添加 更新 PUT 更新 DELETE 删除 来源： https://blog.csdn.net/fql123455/article/details/98957424