小工匠

import com/*** 处理器接口定义/*** 处理 : 返回true ,继续处理，返回false，终止处理* @return/*** 获取处理顺序* @return/*** 处理器接口定义/*** 处理 : 返回true ,继续处理，返回false，终止处理* @return/*** 获取处理顺序* @return/*** 处理器接口定义/*** 处理 : 返回true ,继续处理，返回false，终止处理* @return/**

代理模式有点像⽼⼤和⼩弟，也有点像分销商。主要解决的是问题是为某些资源的访问、对象的类的易⽤操作上提供⽅便使⽤的代理服务。⽽这种设计思想的模式经常会出现在我们的系统中，或者你⽤到过的组件中，它们都提供给你⼀种⾮常简单易⽤的⽅式控制原本你需要编写很多代码的进⾏使⽤的服务类。类似这样的场景还有“”你的数据库访问层⾯经常会提供⼀个较为基础的应⽤，以此来减少应⽤服务扩容时不⾄于数据库连接数暴增。

享元模式，主要在于共享通⽤对象，减少内存的使⽤，提升系统的访问效率。⽽这部分共享对象通常⽐较耗费内存或者需要查询⼤量接⼝或者使⽤数据库资源，因此统⼀抽离作为共享对象使⽤。另外享元模式可以分为在服务端和客户端.⼀般互联⽹H5和Web场景下⼤部分数据都需要服务端进⾏处理，⽐如数据库连接池的使⽤、多线程线程池的使⽤，除了这些功能外，还有些需要服务端进⾏包装后的处理下发给客户端，因为服务端需要做享元处理。但在⼀些游戏场景下，很多都是客户端需要进⾏渲染地图效果，⽐如；

设计模式是解决程序中不合理、不易于扩展、不易于维护的问题，也是⼲掉⼤部分 ifelse 的利器，在我们常⽤的框架中基本都会⽤到⼤量的设计模式来构建组件，这样也能⽅便框架的升级和功能的扩展。但如果不能合理的设计以及乱⽤设计模式，会导致整个编程变得更加复杂难维护，也就是我们常说的: 反设计 、 过渡设计。⽽这部分设计能⼒也是从实践的项⽬中获取的经验，不断的改造优化摸索出的最合理的⽅式，应对当前的服务体量。外观模式也叫⻔⾯模式，主要解决的是降低调⽤⽅的使⽤接⼝的复杂逻辑组合。

装饰器的核⼼就是再不改原有类的基础上给类新增功能。不改变原有类，大家会想到继承、AOP切⾯，当然这些⽅式都可以实现，但是使⽤装饰器模式会是另外⼀种思路更为灵活，可以避免继承导致的⼦类过多，也可以避免AOP带来的复杂性。很多场景⽤到装饰器模式字节流、字符流、⽂件流的内容时都⻅到了这样的代码，⼀层嵌套⼀层，⼀层嵌套⼀层，字节流转字符流等等，⽽这样⽅式的使⽤就是装饰器模式的⼀种体现。

桥接模式的主要作⽤就是通过将抽象部分与实现部分分离，把多种可匹配的使⽤进⾏组合。说⽩了核⼼实现也就是在A类中含有B类接⼝，通过构造函数传递B类的实现，这个B类就是设计的 桥。那么这样的桥接模式，在我们平常的开发中有哪些场景呢？JDBC多种驱动程序的实现、同品牌类型的台式机和笔记本平板、业务实现中的多类接⼝同组过滤服务等。这些场景都⽐较适合使⽤桥接模式进⾏实现，因为在⼀些组合中如果有如果每⼀个类都实现不同的服务可能会出现笛卡尔积，⽽使⽤桥接模式就可以⾮常简单。

适配器模式的主要作⽤就是把原本不兼容的接⼝，通过适配修改做到统⼀。使得⽤户⽅便使⽤，就像我们提到转换头、出国旅游买个插座等等，都是为了适配各种不同的口 ，做的兼容。在业务开发中我们会经常的需要做不同接⼝的兼容，尤其是中台服务，中台需要把各个业务线的各种类型服务做统⼀包装，再对外提供接⼝进⾏使⽤。⽽这在平常的开发中也是⾮常常⻅的。

设计代码架构时，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。依赖倒置原则是实现开闭原则的重要途径之一， 它降低了类之间的耦合，提高了系统的稳定性和可维护性。

接口隔离原则（Interface Segregation Principle, ISP）,要求尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含相关的方法。接口隔离是为了高内聚、低耦合。在实际的开发中，通常都是先定义好需要开发的接口，并由各个服务去实现。但是如果没有经过考虑和设计，很可能造成一个接口中包含了众多的接口方法，而这些接口并不一定在每一个类中都需要实现， 这样的接口很难维护， 也不易于扩展，每一次修改验证都有潜在的风险。在具体应用接口隔离原则时， 应该根据以下几个规则进行考量。

原型模式主要解决的问题就是创建重复对象，⽽这部分 对象 内容本身⽐较复杂，⽣成过程可能从库或者RPC接⼝中获取数据的耗时较⻓，因此采⽤克隆的⽅式节省时间。

创建型模式结构型模式⾏为模式⼯⼚⽅法模式抽象⼯⼚模式建造者模式原型模式除此之外还有最后⼀个 单例模式单例模式可以说是整个设计中最简单的模式之⼀，在编程开发中经常会遇到这样⼀种场景，那就是需要保证⼀个类只有⼀个实例哪怕多线程同时访问，并需要提供⼀个全局访问此实例的点。单例模式主要解决的是，⼀个全局使⽤的类频繁的创建和消费，从⽽提升提升整体的代码的性能。

建造者模式所完成的内容就是通过将多个简单对象通过⼀步步的组装构建出⼀个复杂对象的过程。举个例子玩王者荣耀的时的初始化界⾯；有三条路、有树⽊、有野怪、有守卫塔等等，甚⾄依赖于你的⽹络情况会控制清晰度。⽽当你换⼀个场景进⾏其他不同模式的选择时，同样会建设道路、树⽊、野怪等等，但是他们的摆放和⼤⼩都有不同。这⾥就可以⽤到建造者模式来初始化游戏元素。⽽这样的根据相同的物料 ，不同的组装所产⽣出的具体的内容，就是建造者模式的最终意图，也就是将⼀个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

抽象⼯⼚模式与⼯⼚⽅法模式虽然主要意图都是为了解决，接⼝选择问题。但在实现上，抽象工厂是⼀个中心工厂，创建其他工厂的模式。举个例子：不同系统内的回⻋换⾏Unix系统⾥，每⾏结尾只有 ，即 \n；Windows系统⾥⾯，每⾏结尾是 ，即 \n\r；Mac系统⾥，每⾏结尾是 IDEA 开发⼯具的差异展示(Win\Mac)除了这样显⽽易⻅的例⼦外，我们的业务开发中时常也会遇到类似的问题，需要兼容做处理。但⼤部分经验不⾜的开发⼈员，常常直接通过添加ifelse。

优秀的代码在结构设计上松耦合易读易扩展，在领域实现上⾼内聚不对外暴漏实现细节不被外部⼲扰。⼯⼚模式⼜称⼯⼚⽅法模式，是⼀种创建型设计模式，其在⽗类中提供⼀个创建对象的⽅法， 允许⼦类决定实例化对象的类型。它的主要意图是定义⼀个创建对象的接⼝，让其⼦类⾃⼰决定实例化哪⼀个⼯⼚类，⼯⼚模式使其创建过程延迟到⼦类进⾏。优点： 简单说就是为了提供代码结构的扩展性，屏蔽每⼀个功能类中的具体实现逻辑。让外部可以更加简单的只是知道调⽤即可，同时，这也是去掉众多 ifelse 的⽅式。

迪米特法（Law Of Demeter ， LoD）则又叫最少知道原则（Least Knowledge Principle），最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法有一个经典语录：只与朋友通信，不和陌生人说话。

里氏替换原则（Liskov Substitution Principle , LSP） 由麻省理工学院计算机科学西教授 Barbara Liskov 于1987年提出， 她提出：继承必须确保超类所拥有的性质在子类中仍然成立。

在面向对象编程领域中，开闭原则规定软件中的类、对象、模块和函数对扩展应该是开放的，但对修改是封闭的。这意味着 应该用抽象定义结构，用具体实现扩展细节，以此确保软件系统开发和维护过程的可靠性。开闭原则的核心思想-----> 面向抽象编程。/*** 计算面积，长方形* @param x 长* @param y 宽* @return 面积/*** 计算面积，三角形* @param x 边长x* @param y 边长y* @param z 边长z* @return 面积。

单一职责原则（Single Responsibility Principle， SRP）又称单一功能原则，是面向对象的五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。在程序设计领域，SOLID 是由罗伯特·C·马丁在 21 世纪早期引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，能够使得一个程序员开发一个容易进行维护和扩展的系统变得更加可能。

概述　　有时被称作发布/订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。问题的提出在生活当中，经常会遇到多种数据关注一个对象数据变化的情况。举个例子：生活中有温度记录仪，当温度发生变化时，需要完成一下功能：记录温度日志，显示温度变化曲线，当温度越界是触发扬声器发出声音等等。。。伪代码大

设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。