常用设计模式汇总
单例模式：
即一个应用程序中，某个类的实例对象只有一个，你没有办法去new，因为构造器是被private修饰的，一般通过其get方法获取到他们的实例。
懒汉写法（线程不安全）
publicclasssingleton{ privatestaticsingletonsingleton; privatesingleton(){ } publicstaticsingletongetinstance(){ if(singleton==null){ singleton=newsingleton(); } returnsingleton; } }
懒汉式写法（线程安全）
publicclasssingleton{ privatestaticsingletoninstance; privatesingleton(){} publicstaticsynchronizedsingletongetinstance(){ if(instance==null){ instance=newsingleton(); } returninstance; } }
饿汉式写法
publicclasssingleton{ privatestaticsingletoninstance=newsingleton(); privatesingleton(){} publicstaticsingletongetinstance(){ returninstance; } }
静态内部类
publicclasssingleton{ privatestaticclasssingletonholder{ privatestaticfinalsingletoninstance=newsingleton(); } privatesingleton(){} publicstaticfinalsingletongetinstance(){ returnsingletonholder.instance; } }
枚举
这种方式是effective java作者josh bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏。
publicenumsingleton{ instance; publicvoidwhatevermethod(){ } }
双重校验锁
publicclasssingleton{ privatevolatilestaticsingletonsingleton; privatesingleton(){} publicstaticsingletongetsingleton(){ if(singleton==null){ synchronized(singleton.class){ if(singleton==null){ singleton=newsingleton(); } } } returnsingleton; } }
实际应用场景：
在spring中创建的bean实例默认都是单例模式存在的。
windows的task manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？不信你自己试试看哦~
windows的recycle bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。
网站的计数器，一般也是采用单例模式实现，否则难以同步。
应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
观察者模式：
对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
给你举个栗子：假设有三个人，小美（女，22），小王和小李。小美很漂亮，小王和小李是两个程序猿，时刻关注着小美的一举一动。有一天，小美说了一句：“谁来陪我打游戏啊。”
这句话被小王和小李听到了，结果乐坏了，蹭蹭蹭，没一会儿，小王就冲到小美家门口了，在这里，小美是被观察者，小王和小李是观察者，被观察者发出一条信息，然后观察者们进行相应的处理，看代码：
publicinterfaceperson{ //小王和小李通过这个接口可以接收到小美发过来的消息 voidgetmessage(strings); }
这个接口相当于小王和小李的电话号码，小美发送通知的时候就会拨打getmessage这个电话，拨打电话就是调用接口，看不懂没关系，先往下看
publicclasslaowangimplementsperson{ privatestringname=小王; publiclaowang(){ } @override publicvoidgetmessage(strings){ system.out.println(name+接到了小美打过来的电话，电话内容是：+s); } } publicclasslaoliimplementsperson{ privatestringname=小李; publiclaoli(){ } @override publicvoidgetmessage(strings){ system.out.println(name+接到了小美打过来的电话，电话内容是：->+s); } }
代码很简单，我们再看看小美的代码：
publicclassxiaomei{ listlist=newarraylist(); publicxiaomei(){ } publicvoidaddperson(personperson){ list.add(person); } //遍历list，把自己的通知发送给所有暗恋自己的人 publicvoidnotifyperson(){ for(personperson:list){ person.getmessage(你们过来吧，谁先过来谁就能陪我一起玩儿游戏!); } } }
我们写一个测试类来看一下结果对不对
publicclasstest{ publicstaticvoidmain(string[]args){ xiaomeixiao_mei=newxiaomei(); laowanglao_wang=newlaowang(); laolilao_li=newlaoli(); //小王和小李在小美那里都注册了一下 xiao_mei.addperson(lao_wang); xiao_mei.addperson(lao_li); //小美向小王和小李发送通知 xiao_mei.notifyperson(); } }
实际应用场景：
场景描述：
以购票为核心业务(此模式不限于该业务)，但围绕购票会产生不同的其他逻辑，如：
购票后记录文本日志
购票后记录数据库日志
购票后发送短信
购票送抵扣卷、兑换卷、积分
-其他各类活动等
传统解决方案:
在购票逻辑等类内部增加相关代码，完成各种逻辑。
存在问题：
1、一旦某个业务逻辑发生改变，如购票业务中增加其他业务逻辑，需要修改购票核心文件、甚至购票流程。
2、日积月累后，文件冗长，导致后续维护困难。
存在问题原因主要是程序的紧密耦合，使用观察模式将目前的业务逻辑优化成松耦合，达到易维护、易修改的目的，同时也符合面向接口编程的思想。
观察者模式典型实现方式：
定义2个接口：观察者（通知）接口、被观察者（主题）接口
定义2个类，观察者对象实现观察者接口、主题类实现被观者接口
主题类注册自己需要通知的观察者
主题类某个业务逻辑发生时通知观察者对象，每个观察者执行自己的业务逻辑。
装饰者模式
对已有的业务逻辑进一步的封装，使其增加额外的功能，如java中的io流就使用了装饰者模式，用户在使用的时候，可以任意组装，达到自己想要的效果。
举个栗子，我想吃三明治，首先我需要一根大大的香肠，我喜欢吃奶油，在香肠上面加一点奶油，再放一点蔬菜，最后再用两片面包夹一下，很丰盛的一顿午饭，营养又健康。那我们应该怎么来写代码呢？首先，我们需要写一个food类，让其他所有食物都来继承这个类，看代码：
publicclassfood{ privatestringfood_name; publicfood(){ } publicfood(stringfood_name){ this.food_name=food_name; } publicstringmake(){ returnfood_name; }; }
代码很简单，我就不解释了，然后我们写几个子类继承它：
//面包类 publicclassbreadextendsfood{ privatefoodbasic_food; publicbread(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++面包; } } //奶油类 publicclasscreamextendsfood{ privatefoodbasic_food; publiccream(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++奶油; } } //蔬菜类 publicclassvegetableextendsfood{ privatefoodbasic_food; publicvegetable(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++蔬菜; } }
这几个类都是差不多的，构造方法传入一个food类型的参数，然后在make方法中加入一些自己的逻辑，如果你还是看不懂为什么这么写，不急，你看看我的test类是怎么写的，一看你就明白了
publicclasstest{ publicstaticvoidmain(string[]args){ foodfood=newbread(newvegetable(newcream(newfood(香肠)))); system.out.println(food.make()); } }
看到没有，一层一层封装，我们从里往外看：最里面我new了一个香肠，在香肠的外面我包裹了一层奶油，在奶油的外面我又加了一层蔬菜，最外面我放的是面包，是不是很形象，哈哈~ 这个设计模式简直跟现实生活中一摸一样，看懂了吗？
实际应用场景：
如上述一样，不同的人，选择的搭配不同，对应价格也不相同，若是应用传统方式你会发现这里四种配料就要写十几种实现类了，那如果我们的配料是二十几种或者三十几种呢，那么使用继承这种 方式肯定会使我们的子类爆炸。
通过不同的组合以food food = new bread(new vegetable(new cream(new food(香肠))));形式更加简化，结构更加清楚的方式展现。
优点：
把类中的装饰功能从类中搬除，可以简化原来的类
可以把类的 核心职责和装饰功能区分开来，结构清晰 明了并且可以去除相关类的重复的装饰逻辑。
适配器模式
将两种完全不同的事物联系到一起，就像现实生活中的变压器。假设一个手机充电器需要的电压是20v，但是正常的电压是220v，这时候就需要一个变压器，将220v的电压转换成20v的电压，这样，变压器就将20v的电压和手机联系起来了。
publicclasstest{ publicstaticvoidmain(string[]args){ phonephone=newphone(); voltageadapteradapter=newvoltageadapter(); phone.setadapter(adapter); phone.charge(); } } //手机类 classphone{ publicstaticfinalintv=220;//正常电压220v，是一个常量 privatevoltageadapteradapter; //充电 publicvoidcharge(){ adapter.changevoltage(); } publicvoidsetadapter(voltageadapteradapter){ this.adapter=adapter; } } //变压器 classvoltageadapter{ //改变电压的功能 publicvoidchangevoltage(){ system.out.println(正在充电...); system.out.println(原始电压：+phone.v+v); system.out.println(经过变压器转换之后的电压:+(phone.v-200)+v); } }
适配器模式应用场景
类适配器与对象适配器的使用场景一致，仅仅是实现手段稍有区别，二者主要用于如下场景：
想要使用一个已经存在的类，但是它却不符合现有的接口规范，导致无法直接去访问，这时创建一个适配器就能间接去访问这个类中的方法。
我们有一个类，想将其设计为可重用的类（可被多处访问），我们可以创建适配器来将这个类来适配其他没有提供合适接口的类。
以上两个场景其实就是从两个角度来描述一类问题，那就是要访问的方法不在合适的接口里，一个从接口出发（被访问），一个从访问出发（主动访问）。
接口适配器使用场景：
想要使用接口中的某个或某些方法，但是接口中有太多方法，我们要使用时必须实现接口并实现其中的所有方法，可以使用抽象类来实现接口，并不对方法进行实现（仅置空），然后我们再继承这个抽象类来通过重写想用的方法的方式来实现。这个抽象类就是适配器。
工厂模式
简单工厂模式：一个抽象的接口，多个抽象接口的实现类，一个工厂类，用来实例化抽象的接口
//抽象产品类 abstractclasscar{ publicvoidrun(); publicvoidstop(); } //具体实现类 classbenzimplementscar{ publicvoidrun(){ system.out.println(benz开始启动了。。。。。); } publicvoidstop(){ system.out.println(benz停车了。。。。。); } } classfordimplementscar{ publicvoidrun(){ system.out.println(ford开始启动了。。。); } publicvoidstop(){ system.out.println(ford停车了。。。。); } } //工厂类 classfactory{ publicstaticcargetcarinstance(stringtype){ carc=null; if(benz.equals(type)){ c=newbenz(); } if(ford.equals(type)){ c=newford(); } returnc; } } publicclasstest{ publicstaticvoidmain(string[]args){ carc=factory.getcarinstance(benz); if(c!=null){ c.run(); c.stop(); }else{ system.out.println(造不了这种汽车。。。); } } }
工厂方法模式：有四个角色，抽象工厂模式，具体工厂模式，抽象产品模式，具体产品模式。不再是由一个工厂类去实例化具体的产品，而是由抽象工厂的子类去实例化产品
//抽象产品角色 publicinterfacemoveable{ voidrun(); } //具体产品角色 publicclassplaneimplementsmoveable{ @override publicvoidrun(){ system.out.println(plane....); } } publicclassbroomimplementsmoveable{ @override publicvoidrun(){ system.out.println(broom.....); } } //抽象工厂 publicabstractclassvehiclefactory{ abstractmoveablecreate(); } //具体工厂 publicclassplanefactoryextendsvehiclefactory{ publicmoveablecreate(){ returnnewplane(); } } publicclassbroomfactoryextendsvehiclefactory{ publicmoveablecreate(){ returnnewbroom(); } } //测试类 publicclasstest{ publicstaticvoidmain(string[]args){ vehiclefactoryfactory=newbroomfactory(); moveablem=factory.create(); m.run(); } }
抽象工厂模式：与工厂方法模式不同的是，工厂方法模式中的工厂只生产单一的产品，而抽象工厂模式中的工厂生产多个产品
//抽象工厂类 publicabstractclassabstractfactory{ publicabstractvehiclecreatevehicle(); publicabstractweaponcreateweapon(); publicabstractfoodcreatefood(); } //具体工厂类，其中food,vehicle，weapon是抽象类， publicclassdefaultfactoryextendsabstractfactory{ @override publicfoodcreatefood(){ returnnewapple(); } @override publicvehiclecreatevehicle(){ returnnewcar(); } @override publicweaponcreateweapon(){ returnnewak47(); } } //测试类 publicclasstest{ publicstaticvoidmain(string[]args){ abstractfactoryf=newdefaultfactory(); vehiclev=f.createvehicle(); v.run(); weaponw=f.createweapon(); w.shoot(); fooda=f.createfood(); a.printname(); } }
工厂模式例子很多，我大概说一下上面三种的特点：
简单工厂模式：每次扩展时，需要添加一个类，并修改工厂类代码，给get方法添加一条分支。
工厂方法模式：它与简单工厂的区别就在于有多个工厂，每个工厂只专注生产一种产品，当需要修改获取的产品时，只需要修改所访问的工厂就行。
抽象工厂模式：每次扩展时，需要添加1个类，并添加1个对应工厂。既是优点（扩展灵活，不需要修改旧的类）又是缺点（总是要编写新工厂）。
代理模式（proxy）
有两种，静态代理和动态代理。先说静态代理，很多理论性的东西我不讲，我就算讲了，你们也看不懂。什么真实角色，抽象角色，代理角色，委托角色。。。乱七八糟的，我是看不懂。
之前学代理模式的时候，去网上翻一下，资料一大堆，打开链接一看，基本上都是给你分析有什么什么角色，理论一大堆，看起来很费劲，不信的话你们可以去看看，我是看不懂他们在说什么。咱不来虚的，直接用生活中的例子说话。
注意：我这里并不是否定理论知识，我只是觉得有时候理论知识晦涩难懂，喜欢挑刺的人一边去，你是来学习知识的，不是来挑刺的
到了一定的年龄，我们就要结婚，结婚是一件很麻烦的事情，（包括那些被父母催婚的）。有钱的家庭可能会找司仪来主持婚礼，显得热闹，洋气～好了，现在婚庆公司的生意来了，我们只需要给钱，婚庆公司就会帮我们安排一整套结婚的流程。
整个流程大概是这样的：家里人催婚->男女双方家庭商定结婚的黄道即日->找一家靠谱的婚庆公司->在约定的时间举行结婚仪式->结婚完毕
婚庆公司打算怎么安排婚礼的节目，在婚礼完毕以后婚庆公司会做什么，我们一概不知。。。别担心，不是黑中介，我们只要把钱给人家，人家会把事情给我们做好。所以，这里的婚庆公司相当于代理角色，现在明白什么是代理角色了吧。
代码实现请看：
//代理接口 publicinterfaceproxyinterface{ //需要代理的是结婚这件事，如果还有其他事情需要代理，比如吃饭睡觉上厕所，也可以写 voidmarry(); //代理吃饭(自己的饭，让别人吃去吧) //voideat(); //代理拉屎，自己的屎，让别人拉去吧 //voidshit(); }
文明社会，代理吃饭，代理拉屎什么的我就不写了，有伤社会风化～～～能明白就好
好了，我们看看婚庆公司的代码:
publicclassweddingcompanyimplementsproxyinterface{ privateproxyinterfaceproxyinterface; publicweddingcompany(proxyinterfaceproxyinterface){ this.proxyinterface=proxyinterface; } @override publicvoidmarry(){ system.out.println(我们是婚庆公司的); system.out.println(我们在做结婚前的准备工作); system.out.println(节目彩排...); system.out.println(礼物购买...); system.out.println(工作人员分工...); system.out.println(可以开始结婚了); proxyinterface.marry(); system.out.println(结婚完毕，我们需要做后续处理，你们可以回家了，其余的事情我们公司来做); } }
看到没有，婚庆公司需要做的事情很多，我们再看看结婚家庭的代码:
publicclassnormalhomeimplementsproxyinterface{ @override publicvoidmarry(){ system.out.println(我们结婚啦～); } }
这个已经很明显了，结婚家庭只需要结婚，而婚庆公司要包揽一切，前前后后的事情都是婚庆公司来做，听说现在婚庆公司很赚钱的，这就是原因，干的活多，能不赚钱吗？
来看看测试类代码：
publicclasstest{ publicstaticvoidmain(string[]args){ proxyinterfaceproxyinterface=newweddingcompany(newnormalhome()); proxyinterface.marry(); } }
运行结果如下：
这里可以看出代理模式与装饰模式很相似，这里简单介绍下其区别：
代理模式（proxy 模式）可理解为：我想做，但不能做，我需要有一个能干的人来帮我做。即：代理，偏重因自己无法完成或自己无需关心，需要他人干涉事件流程，更多的是对对象的控制。
装饰器模式（decorator 模式）可理解为：我想做，但不能做，我需要有各类特长的人来帮我做，但我有时只需要一个人，有时又需要很多人。即：装饰，偏重对原对象功能的扩展，扩展后的对象仍是是对象本身。
低噪声信号采集模块概述及技术指标
全球合规化的开源标准和去中心化网络STP介绍
电子[做梦机],dream box
【重磅】NB-IoT标准核心协议冻结 华为助力
Wolfspeed与捷豹TCS赛车队达成战略合作
常用设计模式汇总
以机械手控制为例,分析PLC与步进驱动装置的控制方法
巴西禁售不带充电器iPhone
关于光纤连接器的使用介绍和注意事项
坚果Pro2S和小米8SE哪个最好
利用仿真减少逆变器电路设计工时的方法
为何创牌不足2年的三翼鸟，就有了头部效应？
Mimo智能婴儿服面世 首款搭载英特尔Edison芯片
FBG光纤反射器，FTTX网络链路监控的理想光端
人工智能驱动的医疗机器人的成功之后
戴姆勒引入3D打印技术，重塑供应链节省成本
史海钩沉：关于可编程逻辑，你可能已经遗忘的8件事
小米mix2：oppo叫板小米mix2,国产机哪家强？
中兴通讯助力民生银行推进科技和金融业务深度融合
快讯：AMD 7代APU新品A6-9400悄然上架，28nm双核挖掘机
即一个应用程序中，某个类的实例对象只有一个，你没有办法去new，因为构造器是被private修饰的，一般通过其get方法获取到他们的实例。
懒汉写法（线程不安全）
publicclasssingleton{ privatestaticsingletonsingleton; privatesingleton(){ } publicstaticsingletongetinstance(){ if(singleton==null){ singleton=newsingleton(); } returnsingleton; } }
懒汉式写法（线程安全）
publicclasssingleton{ privatestaticsingletoninstance; privatesingleton(){} publicstaticsynchronizedsingletongetinstance(){ if(instance==null){ instance=newsingleton(); } returninstance; } }
饿汉式写法
publicclasssingleton{ privatestaticsingletoninstance=newsingleton(); privatesingleton(){} publicstaticsingletongetinstance(){ returninstance; } }
静态内部类
publicclasssingleton{ privatestaticclasssingletonholder{ privatestaticfinalsingletoninstance=newsingleton(); } privatesingleton(){} publicstaticfinalsingletongetinstance(){ returnsingletonholder.instance; } }
枚举
这种方式是effective java作者josh bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏。
publicenumsingleton{ instance; publicvoidwhatevermethod(){ } }
双重校验锁
publicclasssingleton{ privatevolatilestaticsingletonsingleton; privatesingleton(){} publicstaticsingletongetsingleton(){ if(singleton==null){ synchronized(singleton.class){ if(singleton==null){ singleton=newsingleton(); } } } returnsingleton; } }
实际应用场景：
在spring中创建的bean实例默认都是单例模式存在的。
windows的task manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？不信你自己试试看哦~
windows的recycle bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。
网站的计数器，一般也是采用单例模式实现，否则难以同步。
应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
观察者模式：
对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
给你举个栗子：假设有三个人，小美（女，22），小王和小李。小美很漂亮，小王和小李是两个程序猿，时刻关注着小美的一举一动。有一天，小美说了一句：“谁来陪我打游戏啊。”
这句话被小王和小李听到了，结果乐坏了，蹭蹭蹭，没一会儿，小王就冲到小美家门口了，在这里，小美是被观察者，小王和小李是观察者，被观察者发出一条信息，然后观察者们进行相应的处理，看代码：
publicinterfaceperson{ //小王和小李通过这个接口可以接收到小美发过来的消息 voidgetmessage(strings); }
这个接口相当于小王和小李的电话号码，小美发送通知的时候就会拨打getmessage这个电话，拨打电话就是调用接口，看不懂没关系，先往下看
publicclasslaowangimplementsperson{ privatestringname=小王; publiclaowang(){ } @override publicvoidgetmessage(strings){ system.out.println(name+接到了小美打过来的电话，电话内容是：+s); } } publicclasslaoliimplementsperson{ privatestringname=小李; publiclaoli(){ } @override publicvoidgetmessage(strings){ system.out.println(name+接到了小美打过来的电话，电话内容是：->+s); } }
代码很简单，我们再看看小美的代码：
publicclassxiaomei{ listlist=newarraylist(); publicxiaomei(){ } publicvoidaddperson(personperson){ list.add(person); } //遍历list，把自己的通知发送给所有暗恋自己的人 publicvoidnotifyperson(){ for(personperson:list){ person.getmessage(你们过来吧，谁先过来谁就能陪我一起玩儿游戏!); } } }
我们写一个测试类来看一下结果对不对
publicclasstest{ publicstaticvoidmain(string[]args){ xiaomeixiao_mei=newxiaomei(); laowanglao_wang=newlaowang(); laolilao_li=newlaoli(); //小王和小李在小美那里都注册了一下 xiao_mei.addperson(lao_wang); xiao_mei.addperson(lao_li); //小美向小王和小李发送通知 xiao_mei.notifyperson(); } }
实际应用场景：
场景描述：
以购票为核心业务(此模式不限于该业务)，但围绕购票会产生不同的其他逻辑，如：
购票后记录文本日志
购票后记录数据库日志
购票后发送短信
购票送抵扣卷、兑换卷、积分
-其他各类活动等
传统解决方案:
在购票逻辑等类内部增加相关代码，完成各种逻辑。
存在问题：
1、一旦某个业务逻辑发生改变，如购票业务中增加其他业务逻辑，需要修改购票核心文件、甚至购票流程。
2、日积月累后，文件冗长，导致后续维护困难。
存在问题原因主要是程序的紧密耦合，使用观察模式将目前的业务逻辑优化成松耦合，达到易维护、易修改的目的，同时也符合面向接口编程的思想。
观察者模式典型实现方式：
定义2个接口：观察者（通知）接口、被观察者（主题）接口
定义2个类，观察者对象实现观察者接口、主题类实现被观者接口
主题类注册自己需要通知的观察者
主题类某个业务逻辑发生时通知观察者对象，每个观察者执行自己的业务逻辑。
装饰者模式
对已有的业务逻辑进一步的封装，使其增加额外的功能，如java中的io流就使用了装饰者模式，用户在使用的时候，可以任意组装，达到自己想要的效果。
举个栗子，我想吃三明治，首先我需要一根大大的香肠，我喜欢吃奶油，在香肠上面加一点奶油，再放一点蔬菜，最后再用两片面包夹一下，很丰盛的一顿午饭，营养又健康。那我们应该怎么来写代码呢？首先，我们需要写一个food类，让其他所有食物都来继承这个类，看代码：
publicclassfood{ privatestringfood_name; publicfood(){ } publicfood(stringfood_name){ this.food_name=food_name; } publicstringmake(){ returnfood_name; }; }
代码很简单，我就不解释了，然后我们写几个子类继承它：
//面包类 publicclassbreadextendsfood{ privatefoodbasic_food; publicbread(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++面包; } } //奶油类 publicclasscreamextendsfood{ privatefoodbasic_food; publiccream(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++奶油; } } //蔬菜类 publicclassvegetableextendsfood{ privatefoodbasic_food; publicvegetable(foodbasic_food){ this.basic_food=basic_food; } publicstringmake(){ returnbasic_food.make()++蔬菜; } }
这几个类都是差不多的，构造方法传入一个food类型的参数，然后在make方法中加入一些自己的逻辑，如果你还是看不懂为什么这么写，不急，你看看我的test类是怎么写的，一看你就明白了
publicclasstest{ publicstaticvoidmain(string[]args){ foodfood=newbread(newvegetable(newcream(newfood(香肠)))); system.out.println(food.make()); } }
看到没有，一层一层封装，我们从里往外看：最里面我new了一个香肠，在香肠的外面我包裹了一层奶油，在奶油的外面我又加了一层蔬菜，最外面我放的是面包，是不是很形象，哈哈~ 这个设计模式简直跟现实生活中一摸一样，看懂了吗？
实际应用场景：
如上述一样，不同的人，选择的搭配不同，对应价格也不相同，若是应用传统方式你会发现这里四种配料就要写十几种实现类了，那如果我们的配料是二十几种或者三十几种呢，那么使用继承这种 方式肯定会使我们的子类爆炸。
通过不同的组合以food food = new bread(new vegetable(new cream(new food(香肠))));形式更加简化，结构更加清楚的方式展现。
优点：
把类中的装饰功能从类中搬除，可以简化原来的类
可以把类的 核心职责和装饰功能区分开来，结构清晰 明了并且可以去除相关类的重复的装饰逻辑。
适配器模式
将两种完全不同的事物联系到一起，就像现实生活中的变压器。假设一个手机充电器需要的电压是20v，但是正常的电压是220v，这时候就需要一个变压器，将220v的电压转换成20v的电压，这样，变压器就将20v的电压和手机联系起来了。
publicclasstest{ publicstaticvoidmain(string[]args){ phonephone=newphone(); voltageadapteradapter=newvoltageadapter(); phone.setadapter(adapter); phone.charge(); } } //手机类 classphone{ publicstaticfinalintv=220;//正常电压220v，是一个常量 privatevoltageadapteradapter; //充电 publicvoidcharge(){ adapter.changevoltage(); } publicvoidsetadapter(voltageadapteradapter){ this.adapter=adapter; } } //变压器 classvoltageadapter{ //改变电压的功能 publicvoidchangevoltage(){ system.out.println(正在充电...); system.out.println(原始电压：+phone.v+v); system.out.println(经过变压器转换之后的电压:+(phone.v-200)+v); } }
适配器模式应用场景
类适配器与对象适配器的使用场景一致，仅仅是实现手段稍有区别，二者主要用于如下场景：
想要使用一个已经存在的类，但是它却不符合现有的接口规范，导致无法直接去访问，这时创建一个适配器就能间接去访问这个类中的方法。
我们有一个类，想将其设计为可重用的类（可被多处访问），我们可以创建适配器来将这个类来适配其他没有提供合适接口的类。
以上两个场景其实就是从两个角度来描述一类问题，那就是要访问的方法不在合适的接口里，一个从接口出发（被访问），一个从访问出发（主动访问）。
接口适配器使用场景：
想要使用接口中的某个或某些方法，但是接口中有太多方法，我们要使用时必须实现接口并实现其中的所有方法，可以使用抽象类来实现接口，并不对方法进行实现（仅置空），然后我们再继承这个抽象类来通过重写想用的方法的方式来实现。这个抽象类就是适配器。
工厂模式
简单工厂模式：一个抽象的接口，多个抽象接口的实现类，一个工厂类，用来实例化抽象的接口
//抽象产品类 abstractclasscar{ publicvoidrun(); publicvoidstop(); } //具体实现类 classbenzimplementscar{ publicvoidrun(){ system.out.println(benz开始启动了。。。。。); } publicvoidstop(){ system.out.println(benz停车了。。。。。); } } classfordimplementscar{ publicvoidrun(){ system.out.println(ford开始启动了。。。); } publicvoidstop(){ system.out.println(ford停车了。。。。); } } //工厂类 classfactory{ publicstaticcargetcarinstance(stringtype){ carc=null; if(benz.equals(type)){ c=newbenz(); } if(ford.equals(type)){ c=newford(); } returnc; } } publicclasstest{ publicstaticvoidmain(string[]args){ carc=factory.getcarinstance(benz); if(c!=null){ c.run(); c.stop(); }else{ system.out.println(造不了这种汽车。。。); } } }
工厂方法模式：有四个角色，抽象工厂模式，具体工厂模式，抽象产品模式，具体产品模式。不再是由一个工厂类去实例化具体的产品，而是由抽象工厂的子类去实例化产品
//抽象产品角色 publicinterfacemoveable{ voidrun(); } //具体产品角色 publicclassplaneimplementsmoveable{ @override publicvoidrun(){ system.out.println(plane....); } } publicclassbroomimplementsmoveable{ @override publicvoidrun(){ system.out.println(broom.....); } } //抽象工厂 publicabstractclassvehiclefactory{ abstractmoveablecreate(); } //具体工厂 publicclassplanefactoryextendsvehiclefactory{ publicmoveablecreate(){ returnnewplane(); } } publicclassbroomfactoryextendsvehiclefactory{ publicmoveablecreate(){ returnnewbroom(); } } //测试类 publicclasstest{ publicstaticvoidmain(string[]args){ vehiclefactoryfactory=newbroomfactory(); moveablem=factory.create(); m.run(); } }
抽象工厂模式：与工厂方法模式不同的是，工厂方法模式中的工厂只生产单一的产品，而抽象工厂模式中的工厂生产多个产品
//抽象工厂类 publicabstractclassabstractfactory{ publicabstractvehiclecreatevehicle(); publicabstractweaponcreateweapon(); publicabstractfoodcreatefood(); } //具体工厂类，其中food,vehicle，weapon是抽象类， publicclassdefaultfactoryextendsabstractfactory{ @override publicfoodcreatefood(){ returnnewapple(); } @override publicvehiclecreatevehicle(){ returnnewcar(); } @override publicweaponcreateweapon(){ returnnewak47(); } } //测试类 publicclasstest{ publicstaticvoidmain(string[]args){ abstractfactoryf=newdefaultfactory(); vehiclev=f.createvehicle(); v.run(); weaponw=f.createweapon(); w.shoot(); fooda=f.createfood(); a.printname(); } }
工厂模式例子很多，我大概说一下上面三种的特点：
简单工厂模式：每次扩展时，需要添加一个类，并修改工厂类代码，给get方法添加一条分支。
工厂方法模式：它与简单工厂的区别就在于有多个工厂，每个工厂只专注生产一种产品，当需要修改获取的产品时，只需要修改所访问的工厂就行。
抽象工厂模式：每次扩展时，需要添加1个类，并添加1个对应工厂。既是优点（扩展灵活，不需要修改旧的类）又是缺点（总是要编写新工厂）。
代理模式（proxy）
有两种，静态代理和动态代理。先说静态代理，很多理论性的东西我不讲，我就算讲了，你们也看不懂。什么真实角色，抽象角色，代理角色，委托角色。。。乱七八糟的，我是看不懂。
之前学代理模式的时候，去网上翻一下，资料一大堆，打开链接一看，基本上都是给你分析有什么什么角色，理论一大堆，看起来很费劲，不信的话你们可以去看看，我是看不懂他们在说什么。咱不来虚的，直接用生活中的例子说话。
注意：我这里并不是否定理论知识，我只是觉得有时候理论知识晦涩难懂，喜欢挑刺的人一边去，你是来学习知识的，不是来挑刺的
到了一定的年龄，我们就要结婚，结婚是一件很麻烦的事情，（包括那些被父母催婚的）。有钱的家庭可能会找司仪来主持婚礼，显得热闹，洋气～好了，现在婚庆公司的生意来了，我们只需要给钱，婚庆公司就会帮我们安排一整套结婚的流程。
整个流程大概是这样的：家里人催婚->男女双方家庭商定结婚的黄道即日->找一家靠谱的婚庆公司->在约定的时间举行结婚仪式->结婚完毕
婚庆公司打算怎么安排婚礼的节目，在婚礼完毕以后婚庆公司会做什么，我们一概不知。。。别担心，不是黑中介，我们只要把钱给人家，人家会把事情给我们做好。所以，这里的婚庆公司相当于代理角色，现在明白什么是代理角色了吧。
代码实现请看：
//代理接口 publicinterfaceproxyinterface{ //需要代理的是结婚这件事，如果还有其他事情需要代理，比如吃饭睡觉上厕所，也可以写 voidmarry(); //代理吃饭(自己的饭，让别人吃去吧) //voideat(); //代理拉屎，自己的屎，让别人拉去吧 //voidshit(); }
文明社会，代理吃饭，代理拉屎什么的我就不写了，有伤社会风化～～～能明白就好
好了，我们看看婚庆公司的代码:
publicclassweddingcompanyimplementsproxyinterface{ privateproxyinterfaceproxyinterface; publicweddingcompany(proxyinterfaceproxyinterface){ this.proxyinterface=proxyinterface; } @override publicvoidmarry(){ system.out.println(我们是婚庆公司的); system.out.println(我们在做结婚前的准备工作); system.out.println(节目彩排...); system.out.println(礼物购买...); system.out.println(工作人员分工...); system.out.println(可以开始结婚了); proxyinterface.marry(); system.out.println(结婚完毕，我们需要做后续处理，你们可以回家了，其余的事情我们公司来做); } }
看到没有，婚庆公司需要做的事情很多，我们再看看结婚家庭的代码:
publicclassnormalhomeimplementsproxyinterface{ @override publicvoidmarry(){ system.out.println(我们结婚啦～); } }
这个已经很明显了，结婚家庭只需要结婚，而婚庆公司要包揽一切，前前后后的事情都是婚庆公司来做，听说现在婚庆公司很赚钱的，这就是原因，干的活多，能不赚钱吗？
来看看测试类代码：
publicclasstest{ publicstaticvoidmain(string[]args){ proxyinterfaceproxyinterface=newweddingcompany(newnormalhome()); proxyinterface.marry(); } }
运行结果如下：
这里可以看出代理模式与装饰模式很相似，这里简单介绍下其区别：
代理模式（proxy 模式）可理解为：我想做，但不能做，我需要有一个能干的人来帮我做。即：代理，偏重因自己无法完成或自己无需关心，需要他人干涉事件流程，更多的是对对象的控制。
装饰器模式（decorator 模式）可理解为：我想做，但不能做，我需要有各类特长的人来帮我做，但我有时只需要一个人，有时又需要很多人。即：装饰，偏重对原对象功能的扩展，扩展后的对象仍是是对象本身。
低噪声信号采集模块概述及技术指标
全球合规化的开源标准和去中心化网络STP介绍
电子[做梦机],dream box
【重磅】NB-IoT标准核心协议冻结 华为助力
Wolfspeed与捷豹TCS赛车队达成战略合作
常用设计模式汇总
以机械手控制为例,分析PLC与步进驱动装置的控制方法
巴西禁售不带充电器iPhone
关于光纤连接器的使用介绍和注意事项
坚果Pro2S和小米8SE哪个最好
利用仿真减少逆变器电路设计工时的方法
为何创牌不足2年的三翼鸟，就有了头部效应？
Mimo智能婴儿服面世 首款搭载英特尔Edison芯片
FBG光纤反射器，FTTX网络链路监控的理想光端
人工智能驱动的医疗机器人的成功之后
戴姆勒引入3D打印技术，重塑供应链节省成本
史海钩沉：关于可编程逻辑，你可能已经遗忘的8件事
小米mix2：oppo叫板小米mix2,国产机哪家强？
中兴通讯助力民生银行推进科技和金融业务深度融合
快讯：AMD 7代APU新品A6-9400悄然上架，28nm双核挖掘机