设计原则

时间过的很快，2019 年过去了，迎来了崭新的 2020。 今天做一个 2019 年终总结，算是对 2019 年的一个交代。 主要总结下 2019 年技术上的 成长、读书、理财、时间管理 方面的东西。 技术 关于 Kotlin 翻开 2019 年第一篇博客，竟然是 2019-1-2 晚上 1:27 发表的，真不敢想象 2019 年初还这么作，不把健康放在心上。现在呢，嗯，10 点半就得睡觉了。 2019 年初系统的学习了下 Kotlin 相关的技术，写了 3 篇关于 Kotlin 的文章。 虽然只有 3 篇，但是有几篇的文章字数是 3-4 万。其实这 3 篇如果进行细分的话可以写很多博客，形成一个体系。 文章的数量不重要，重要的是质量。我习惯一篇文章，把所有的事情讲完。 这些文章基本涵盖了 Kotlin 基本的语法和常用的特性。 我们知道 Kotlin 编译后也是 class 字节码， 在介绍 Kotlin 语法糖的时候不仅仅介绍怎么用，还介绍了它背后的实现原理，语法糖对应的 Java 是什么？ 这样对于熟悉 Java 的开发人员来说，可以更快、更加深入的掌握 Kotlin。让我们写的每一行 Kotlin 代码更加自信。 这三篇文章分别为： Kotlin 基础入门详解 Kotlin 操作符重载详解 从 Java 角度深入理解 Kotlin 然后 2019 年 6 月份，在 CSDN

单一职责原则 全称：Single Responsibility Principle 缩写：SRP 定义：就一个类而言，应该仅有的一个引起变化的原因。 通俗一点：一个类中应该是一组相关性很高的函数、函数封装。 说白了模块划分 案例：简单图片加载框架进行演示 开闭原则 全称：Open Close Principle 缩写：OCP 定义：对扩展是开放的,对修改是关闭的 案例：简单图片缓存框架 里氏替换原则 全称：Liskov Substitution Principle 缩写：LSP 定义：任何一个基类可以出现的地方，子类一定可以出现，并且不会产生任何错误（注意:必须是父子关系） 总结： 第一个注意：里氏替换原则核心就是抽象（继承和接口） 每一个子类都会拥有父类的方法属性。 第二个注意：开闭原则和里氏替换原则生死相依，通过里氏替换原则达到了对外开放，对修改关闭。 依赖导致原则 全称：Dependence inversion Principle 缩写：DIP 定义：高层次模块不依赖于低层次模块实现细节 A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。 B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。 通俗一点：说白了，依赖于抽象，不依赖于具体实现。 指导子类实现功能细节 接口隔离原则 全称：Interface Segregation Principle 缩写：ISP

一、简介 设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的 解决方案 。 二、六大原则 a、单一职责原则 【基本介绍】 对类来说的，即 一个类应该只负责一项职责 。如类A负责两个不同职责：职责1，职责2。 当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为 A1，A2 【注意事项和细节】 降低类的复杂度，一个类只负责一项职责 提高类的可读性，可维护性 降低变更引起的风险 通常情况下， 我们应当遵守单一职责原则 ，只有逻辑足够简单，才可以在代码级违 反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原 b、接口隔离原则 【基本介绍 】 客户端不应该依赖它不需要的接 口，即一个类对另一个类的依赖 应该建立在最小的接口上 c、依赖倒转（DIP）原则 【基本介绍】 d、里氏替换原则 e、开闭原则ocp f、迪米特法则 来源： https://www.cnblogs.com/liugp/p/12082823.html

单一职责原则(Single Responsibility Principle, SRP)是Bob大叔提倡的S.O.L.I.D五大设计原则中的第一个。其中，职责(Responsibility)被表述为“变化的原因”(reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。但如果光从字面去理解，SRP很容易让人望文生义产生误解。本文希望能阐明SRP的本质，达到避免误解和指导设计的目的。 动机 对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。 多功能与单变化 对于单功能的类来讲，比较容易遵循SRP，比如：把string转换为DateTime类型的工具类。理解SRP的难点在于在多功能类的情形，即不容易理解多功能与单变化的矛盾。让我们先来看一个Modem类的例子，Modem具有4个功能：拨号，挂断，发送数据，接收数据： class Modem { public void Dial(string aPno) {…} public void Hangup() {…} public void Send(char aData) {…} public char Receive()

组合/聚集复用原则 组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）.组合和聚合都是对象建模中关联（Association）关系的一种.聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。一个合成关系中成分对象是不能与另外一个合成关系共享。 组合/聚合和继承是实现复用的两个基本途径。合成复用原则是指尽量使用合成/聚合，而不是使用继承。 只有当以下的条件全部被满足时，才应当使用继承关系。 1. 子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分“Has-A”和“Is-A”.只有“Is-A”关系才符合继承关系，“Has-A”关系应当使用聚合来描述。 2 .永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。 3 .子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。 错误的使用继承而不是合成/聚合的一个常见原因是错误地把“Has-A”当成了“Is-A”.”Is-A

RESTful架构优点： 前后端分离，减少流量 安全问题集中在接口上，由于接受json格式，防止了注入型等安全问题 前端无关化，后端只负责数据处理，前端表现方式可以是任何前端语言（android，ios,html5） 前端和后端人员更加专注于各自开发，只需接口文档便可完成前后端交互，无需过多相互了解 服务器性能优化：由于前端是静态页面，通过nginx便可获取，服务器主要压力放在了接口上 一、RestFul简介 　　REST（Representational State Transfer 通常被翻译为“表述性状态传输”或者“表述性状态转移”）是RoyFielding提出的一个描述互联系统架构风格的名词。为什么称为REST？Web本质上由各种各样的资源组成，资源由URI 唯一标识。浏览器（或者任何其它类似于浏览器的应用程序）将展示出该资源的一种表现方式，或者一种表现状态。如果用户在该页面中定向到指向其它资源的链接，则将访问该资源，并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移，也即所谓REST。 　　简单地来说REST它是一种使用URL来定位资源，使用HTTP请求描述操作的Web服务规范。REST主要包括以下几方面： 　　（1） REST是一组架构约束条件和原则，而满足这些约束条件和原则的应用程序就是RESTful。 　　（2

开闭原则 基本介绍 开闭原则(Open-Closed Principle, OCP)，是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则，是由 Bertrand Meyer于1988年提出 ，意为一个软件实体应当 对扩展开放，对修改关闭 。即软件实体应尽量在不修改原有代码的情况下进行扩展。 任何软件系统都需要面临一个很重要的问题，即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时，我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延展性。随着软件规模越来越大，软件寿命越来越长，软件维护成本越来越高，设计满足开闭原则的软件系统也变得越来越重要。 为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在Java编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。 代码示例 下面是一个未经重构的计算机器类： public class CalculatorUtils { /** * 计算 * * @param

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 迪米特法则: 一个软件实体应当尽可能少地与其它实体发生相互作用. 如果一个系统符合迪米特法则, 那么当其中某一个模块发生修改时, 就会尽量少地影响其他模块, 扩展会相对容易, 这是对软件实体之间通信的限制, 迪米特法则要求限制软件实体之间通信的宽度和深度. 迪米特法则可降低系统的耦合度, 使类与类之间保持松散的耦合关系. 迪米特法则还有几种定义形式, 包括: 不要和"陌生人"说话, 只与你的直接朋友通信 等, 在迪米特法则中, 对于一个对象他的朋友包括以下几类: 当前对象本身. 以参数形式传入当前对象/方法中的对象. 当前对象的成员对象. 如果当前对象的成员对象是一个集合, 那么集合中的元素也都是朋友. 当前对象所创建的对象. 任何一个对象, 在满足上面的条件之一, 就是当前对象的朋友, 否则就是陌生人. 在应用迪米特法则时, 一个对象只能与直接朋友发生交互, 不要和陌生人发生直接交互, 这丫很难过做可以降低系统的耦合度, 一个对象的改变不会给太多其他度夏宁带来影响. 迪米特法则要求我们在设计系统时候, **应该尽量减少系统之间的交互, 如果两个对象之间不必彼此直接通信, 那么这两个对象就不应该发生任何的直接的相互作用, 如果其中一个对象需要调用另一个对象的某一个方法, 可以通过第三者转发这个调用. **简言之

3.1 依赖倒置原则的定义 依赖倒置原则（Dependence Inversion Principle，简称DIP）这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思？依赖倒置原则的原始定义是：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语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。依赖倒置原则在Java语言中的表现就是： 模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；

设计原则和设计模式的关系 面向对象的分析设计，需要遵循六大设计原则，这些设计原则大都会从思想上指导面向对象分析设计的正确方向，掌握这些原则能帮助我们更好的理解面向对象的概念，也能更好的理解设计模式。因为在实际开发中，也需要综合考虑业务需求、功能、实现难度、系统性能、时间与空间等很多方面的问题，所以很少做到完全遵守，总是在有意无意的违反一些或者是部分设计原则，这时便需要综合权衡其利弊。 设计模式是针对某个场景下某些问题的某个具体的解决方案。也就是说设计模式就是这些设计原则的一些具体的体现，因此设计模式也是应该遵守这些原则的。所以，学习设计模式，首先要学习的就是设计原则。 六大设计原则 单一职责原则——SRP 开闭原则——OCP 里式替换原则——LSP 依赖倒置原则——DIP 接口隔离原则——ISP 迪米特原则——LOD 六大设计原则关系图 1. 1.单一职责原则 （Single Responsibility Principle） 单一职责原则，简称SRP，定义是应该有且仅有一个类引起类的变更，即：一个类只负责一个职责。 优点： 类的复杂性降低，实现什么职责都有明确的定义； 逻辑变得简单，类的可读性提高了，而且，因为逻辑简单，代码的可维护性也提高了； 变更的风险降低，因为只会在单一的类中的修改。 2.里氏替换原则 （Liskov Substitution Principle）