设计模式

简介 背景 ：在程序设计中，客户端一个请求可能需要多个对象中的某一个去处理，客户端了解每个处理对象无疑增加难度，且耦合度高。 如果采用责任链模式就能很好解决该问题。 定义 ：为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。 在责任链模式中，客户端只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，请求会自动进行传递。所以责任链将请求的发送者和请求的处理者解耦了。 优点 ：降低了对象之间的耦合度，使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息；增强了系统的可扩展性，可以根据需要增加新的请求处理类，满足开闭原则；增强了给对象指派职责的灵活性，当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任；责任链简化了对象之间的连接，每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句；责任分担，每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。 缺点 ： 不能保证每个请求一定被处理，由于一个请求没有明确的接收者

​这篇文章我们继续说架构师大刘的故事： 老田升职了，年薪涨到了百万级别！ 这是大刘在加班搞技术攻坚的时候，听别的同事聊了那么一嘴。 大刘心里不是滋味儿。老田和大刘其实在这家公司之前就是同事了，老田能到这家公司，说起来还是大刘推荐的。 但是，在公司的这几年，老田越来越受领导赏识，到如今，晋升成功，赫然成了大刘的上司。大刘百思不得其解。 大刘和老田本身在前家公司都是高级程序员，前后脚跳槽到了现在这家公司。 大刘来得早，成了架构师。老田呢，技术本就不如大刘，被大刘拉来后，先是当了个高级工程师，只是为了避嫌，没跟大刘一个团队。 后来，老田被那时候的 Leader 赏识，做了带项目的组长，再后来，就是现在成功地晋升总监了。而大刘，好几年了却依然在架构师这岗位原地踏步，动弹不得。 大刘陷入了浓浓的迷茫，他自问自己工作态度毫无问题，做事情也兢兢业业。公司的技术攻关，经常也是大刘牵头搞定。公司的技术培训，作为架构师的大刘俨然是一个非常权威的大牛讲师 。 就算是老田，也需要时不时去找大刘请教一些技术难题和技术方向。可是，即使这样，在公司技术领域造诣很深的大刘，却依然没有获得晋升之阶，被老田压了一头。 大刘没忍住，找了个不忙的日子，拉着老田去了个小饭馆，在饭桌上，大刘就说起了他自己的尴尬处境以及对老田升职加薪的不解。 老田对大刘并没有藏着掖着，在饭桌上，他和大刘坦诚沟通了他的经验

基本介绍 适配器模式将某个类的接口转换成客户端期望的另一个接口表示，主要目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。 适配器模式属于结构性模式，主要分为三类：类适配器模式、对象适配器模式、接口适配器模式。 类适配器模式 什么是类适配器模式 类适配器模式介绍：Adapter类，通过集成src类，实现dst类接口，完成src>dst的适配。 应用实例 案例 以生活中充电器的例子来讲解适配器，充电器本身相当于Adapter，220V交流电相当于src（即被适配者），我们的dst（即目标）是5V直流电。 思路分析 代码实现 1 //被适配的类 2 public class Voltage220V { 3 //输出220V的电压 4 public int output220V () { 5 int src= 220 ; 6 System.out.println( "电源电压=" +src+ "伏" ); 7 return src; 8 } 9 } 1 //适配接口 2 public interface IVoltage5V { 3 int output5V () ; 4 } 1 public class VoltageAdapter extends Voltage220V implements IVoltage5V { 2 @Override 3 public int

来源：GitHubPorn 大家好，我是小 P。 最近很多小伙伴找我要一些 设计模式 基础资料，于是我翻箱倒柜，把这份字节跳动大牛总结的设计模式归纳笔记找出来，免费共享给大家！ 据说有小伙伴靠这份笔记顺利进入 BAT 哦，所以一定要好好学习这份资料！ 资料介绍 这份资料非常全面且详细，覆盖了 设计模式 基础学习的方方面面，非常适合初学者入门！ 资料也按目录进行编排，每一章下面都有更具体的内容： 有趣的插图： 如何获取？ 1. 识别并关注下方公众号； 2. 在下面公众号后台回复关键字「 设计模式 」。 👆长按上方二维码 2 秒 回复「 设计模式 」即可获取资料 本文分享自微信公众号 - 程序员小灰（chengxuyuanxiaohui）。 如有侵权，请联系 support@oschina.cn 删除。 本文参与“ OSC源创计划 ”，欢迎正在阅读的你也加入，一起分享。 来源： oschina 链接： https://my.oschina.net/u/4543837/blog/4680161

首先我们看一下为什么要掌握自己的OS。为什么扑街率奇高，美国的科技公司还是一个接一个地要搞自己的OS。OS是软件和硬件的结合层，上面支撑软件运行，下面调度硬件工作。自己控制了OS，上可以辅助软件开发，下可以制定硬件规范。而且涉及并控制大量的第三方公司合作，能让一个科技公司从生态上的一个普通节点，变成一个生态的核心。最早看到鸿蒙OS的宣传的时候，华为还在宣传自己的“Plan B”，就是说他们供应链上任何东西受到威胁的时候，都有自己的后备计划。鸿蒙就是其中之一。所以我确实一开始认为鸿蒙OS是华为从头开始自研的一个操作系统。因为华为从做通讯硬件起家，为自己的通讯硬件产品开发一套微内核，原生支持分布式的OS，作为“Plan B”是非常合理的。因为华为有这样的应用场景，也有自己的硬件系统，这个一个生态系统是立得住的。结合一下我一开始写的为什么要有自己的OS，这样的OS生态系统会是很强大的。我记得那个时候我还跟家人吹，华为真是nb，能够搞定一整套操作系统生态，说明华为真的有一个世界顶级的软件开发团队了。现在想想真是尴尬。但是，从现在公布的所有信息（代码，文档，以及发布时间）来看，鸿蒙并不是一个华为内部酝酿已久的“Plan B”，在最早公布的时候，就是一个PPT的状态。几个高管和高级工程师拍脑袋拍出了一堆时间点，然后掐着节点适当放点东西出来让水军吹牛，让粉丝高潮。这两个之间是有天壤之别的。前者

Java中如何实现代理机制(JDK、CGLIB) JDK动态代理：代理类和目标类实现了共同的接口，用到InvocationHandler接口。 CGLIB动态代理：代理类是目标类的子类，用到MethodInterceptor接口。 多线程的实现方式 继承Thread类、实现Runnable接口、使用ExecutorService、Callable、Future实现有返回结果的多线程。 ServletContext,Listener,Filter和自启动Servlet的执行顺序 应用上下文：即程序上下文，也就是整个程序，可以把它想做一个容器，里面可以放各种各样的变量，这个容器能被整个程序共享，一个用户能拥有多个request，一个用户只能拥有一个session，那么这个上下文就是所有用户有且只能拥有一个，类似于spring的容器的概念。 上下文对象即ServletContext，此对象就是应用上下文了，好比spring中的ApplicationContext 我们在应用spring框架进行依赖注入的时候，依赖注入的方式一般分为两种，xml文件配置和注解形式，除了这两种方式外，还可以通过先从ServletContext上下文中将ApplicationContext取到，然后直接通过ApplicationContext.getBean(name)获取你想要的对象。形象的比喻

记得去年 11 月份，刚入职的时候，领导把我分配到一个翻新老项目的项目组中。 当初，刚进入公司还是蛮激动的，看到这个有点年纪的老项目，打开编辑器，看了看代码，我差点忍不住哭了。 心里暗想，“这是哪位离职的老前辈写的代码，这口锅我真不想背”，功能模块没有任何注释，业务逻辑从头到尾写下来的，没有代码规范，看着这一堆老代码，我无从下手。 这时背后一个人，拍了拍我肩膀，我一下子缓过神来，原来是项目组的负责人。 鹿呀，我们这个老项目，在此基础上，要增加一个功能，这个功能就交给你去做了，项目快到上线了，今天尽快完成吧。然后把大体功能和我说了一通。 没办法，只能硬着头皮去搞，我找到了那个功能页面的代码，正开始屡屡业务逻辑，下面一个代码结构让我眼前一亮。 1if(type == 'fn1'){ // 功能1 2 let a = 1; 3 let arr = []; 4 // 具体功能实现 5 // ... 6 7}else if(type == 'fn2'){ // 功能2 8 // 具体功能实现 9 // ... 10 11}else if(type == 'fn3'){ // 功能3 12 // 具体功能实现 13 // ... 14 15}else if(type == 'fn4'){ // 功能4 16 // 具体功能实现 17 // ... 18 19}else if(type ==

在分布式系统中著有 CAP 理论，该理论由加州大学伯克利分校的 Eric Brewer 教授提出，阐述了在一个分布式系统中不可能同时满足 一致性（Consistency） 、 可用性（Availability） ，以及 分区容错性（Partition tolerance） 。 C：一致性 在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致。 A：可用性 可用性描述了系统对用户的服务能力，所谓可用是指在用户容忍的时间范围内返回用户期望的结果。 P：分区容错性 分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。 对于一个分布式系统而言，我们要始终假设网络是不可靠的，因此分区容错性是对一个分布式系统最基本的要求，我们的切入点更多的是尝试在可用性和一致性之间寻找一个平衡点，但这也并非要求我们在系统设计时一直建立在网络出现分区的场景之上，然后对一致性和可用性在选择时非此即彼。实际上 Eric Brewer 在 2012 年就曾指出 CAP 理论证明不能同时满足一致性、可用性，以及分区容错性的观点在实际系统设计指导上存在一定的误导性 。传统对于 CAP 理论的理解认为在设计分布式系统时必须满足 P，然后在

一、命令的基本格式 [root@localhost~] root为用户名 ～表示当前所在位置 localhost主机名 ‘#’超级用户 '$" 普通用户 命令的基本格式： 命令 [选项] [参数] 二、查询目录的内容 命令格式： ls [选项] [文件或目录] 选项： -a 所有文件 -l 查看详情 -d查看目录属性 -h显示文件大小 三、文件处理命令 1、建立目录 mkdir -p [目录名] -p表述递归建文件夹 举例： mkdir japan mkdir -p japan/cangjk 2.切换目录 cd [目录] 简化操作： cd~ 进入当前用户目录 cd- 上次目录 cd.. 进入上一级目录 pwd查看当前目录所在位置 3.删除目录 rmdir [目录] 删除所有文件 rm -rf [目录] 删除目录所有文件 4.复制目录 cp [选项] [原文件目录] [目标目录] 选项： -r复制目录 -p连文件属性一起复制 -a 相当于-pdr 5.剪切、改名 mv [原文件目录] [目标文件目录] 6.常见目录作用 / 根目录 /bin 命令保存目录 /boot 启动目录 /dev 设备文件命令 /etc 配置文件保存目录 /home 家目录 /lib 系统库保存命令 /mnt 系统挂载目录 三、文件搜索命令 1.locate locate [文件名] 在系统数据库中查找文件的

初级、中级和高级工程师并不是通过你从事编码工作的年限来判断的。初级工程师有时可能比高级工程师工作时间还要长。能否成为更高等级的工程师完全取决于你对专业技能的掌握程度，这也不是说高级工程师必须在每一方面都是专家，但是可以肯定的是，高级工程师一定比初级和中级工程师更加专业。<!-- more --> 不仅仅是编程能力更加专业，高级工程师和初中级工程师相比还有其他区别。这区别到底是什么呢？ 知识 很明显，高级工程师需要掌握更多的知识。学习设计模式、架构、自动化测试、性能、安全等知识是初级工程师迈向中高级工程师的必经之路。 知道软件开发过程中需要做什么是一件非常重要的事情。但是当你掌握了上面所说的全部知识时，你并不是已经成为高级工程师了，这些知识只是不同等级工程师之间的区别之一。 编码 很多人认为编码是人和计算机之间的一种交流，实际上是人和人的交流然后用于指导计算机。代码最终还需要编译成二进制码。 你的代码需要保证可读性，这样以后其他开发者才能在这基础上做其他工作。最好能做到让一个从来没有看过你的代码的团队一打开就能立即进行新功能开发或者修复bug。这也是初级和高级工程师的区别之一。 这里我们忽略了中级工程师，因为中级工程师在编程能力的比较中处于灰色地带。因为中级工程师介于初级与高级之间，并且更倾向于高级。编码能力更更加依赖于经验，而中级工程师通常至少参与过一次完整的软件开发流程