咖啡牛奶

设计模式是一种思想，是一种表达方法，充分理解设计模式，能很好的举出各种设计模式的隐喻，然后在日常的代码工作中，将设计模式的思想实现到我们的代码中，好的设计模式能使我们的代码有更好的封装性，可读性和扩展性。 桥设计模式从字面理解，就是在对象之间起到桥梁的作用，例如我们要表达一个抽象行为，对牛奶的两个平行操作，大杯咖啡和小杯咖啡，加牛奶咖啡和不加牛奶咖啡，因此可能产生加牛奶的大杯咖啡，不加牛奶的大杯咖啡，加牛奶的小杯咖啡，不加牛奶的小杯咖啡，四种状态。在面向对象的世界里，最愚笨的方法当然就是我们创建四个类，每个类表述一种状态，当然这不可取，这种情况我们来看看桥设计模式的妙处吧。如图： 我们定义行为抽象类 我们定义实体抽象类 两种咖啡实体类 两种行为的实体类 下面我们来看下该怎么调度对象 来源： oschina 链接： https://my.oschina.net/u/864445/blog/88214

什么是装饰者模式？ 装饰者模式以对客户透明的方式动态地给一个对象附加上更多的责任，装饰者模式相比生成子类可以更灵活地增加功能。 Component:一般是一个抽象类（也有可能不是），是一组有着某种用途类的基类，包含着这些类最基本的特性。 ConcreteComponent：继承自Component，一般是一个有实际用途的类，这个类就是我们以后要装饰的对象。 Decorator：继承自Component，装饰者需要共同实现的接口（也可以是抽象类），用来保证装饰者和被装饰者有共同的超类，并保证每一个装饰者都有一些必须具有的性质，如每一个装饰者都有一个实例变量（instance variable）用来保存某个Component类型的类的引用。 ConcreteDecorator：继承自Decorator，用来装饰Component类型的类（不能装饰抽象类），为其添加新的特性，可以在委托被装饰者的行为完成之前或之后的任意时候。 下面我们以星巴兹咖啡订单管理系统 管理、计算各种饮料的售价为例，对装饰者模式展开讨论。 设计思路及代码实现 继承 可能我们的第一印象就是继承。 首先定义一个咖啡基类 对于加糖的，加牛奶的，加摩卡的 ，加奶泡的，分别写一个子类继承 对于加糖，又加奶的写一个类，对于对于加糖，又摩卡的写一个类，对于对于加糖、又奶泡的写一个类，对于加糖，又加奶、摩卡的写一个类。

装饰器模式能够在不改 变对象自身的基础上，在程序运行期间给对象 动态地添加职责。遵循开闭原则（应该对于扩展是开放的，对修改是关闭的，即实体应当通过扩展实现变化，而不是修改代码实现变化），利用继承和组合的方式解耦对象间的关系。 例子 以常见的案列咖啡为例。在不考虑设计模式的时候，按照传统的思路，我们会写一个父类表示纯咖啡，如果不能满足需要，就在添加一个加牛奶的咖啡的类去继承咖啡父类，如果还想要加糖，那么在创建一个加糖的类继承父类，这样虽然解决了问题，但是子类膨胀，不利于管理。 以装饰器模式进行开发的话，需要先定一个顶层的接口，对咖啡的行为进行规范 public interface Coffee { String getName(); double getPrice(); } 由于咖啡中需要加各种材料，独把它抽象出来，将其设计成一个抽象类，让子类去添加材料。 public abstract class CoffeeAbstractor implements Coffee { private Coffee coffee; public CoffeeAbstractor(Coffee coffee) { this.coffee = coffee; } @Override public String getName() { return coffee.getName(); }

前言 今天是2020年的第一天，在这里祝大家元旦快乐！之前用 kotlin实现了策略模式 ，文中写到要多写几篇文章来加深以下对设计模式的理解。那么今天要写的看题目应该就知道了：装饰者模式（也叫装饰模式）。下面是装饰者模式的定义： 装饰者模式（Decorator） ：在不改变对象自身的基础上，动态地给一个对象添加一些额外的职责。与继承相比，装饰者是一种更轻便灵活的做法。若要扩展功能，装饰者提供了比继承更有弹性的替代方法。 故事场景 小星刚毕业，到一家公司实习。今天来到公司后，一如既往地开始编写它的增删改查。 刚刚坐下打开电脑，技术锦鲤走了过来，小星内心开始发牢骚（锦鲤来干啥，每回它来都没好事）。锦鲤告诉小星，公司想要编写一个卖咖啡的系统，有不同种类的咖啡，需要能计算出咖啡的钱和区分咖啡的类别。 小星：没问题，很简单。 十分钟后，小星写出了它的第一版代码： 咖啡的基类： abstract class Beverage(var description: String = "Unknown Beverage") { //描述 open fun getDescriptions():String{ return description } //价钱 abstract fun cost():Double } 其他咖啡（子类）： /** * 深度烘焙咖啡(星巴克) * * @author

按照单一职责原则，某一个对象只专注于干一件事，而如果要扩展其职能的话，不如想办法分离出一个类来“包装”这个对象，而这个扩展出的类则专注于实现扩展功能。 装饰器模式就可以将新功能动态地附加于现有对象而不改变现有对象的功能。 1.装饰器模式 实际上Java提供的工具包中，IO相关工具就普遍大量使用了装饰器模式，例如充当装饰功能的IO类如BufferedInputStream等，又被称为高级流，通常将基本流作为高级流构造器的参数传入，将其作为高级流的一个关联对象，从而对其功能进行扩展和装饰。 装饰器模式(Decorator Pattern)，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式比生成子类更灵活。 ----《大话设计模式》 装饰器模式使用分层对象，动态透明地对单个对象添加职责。 下面是装饰器模式的UML类图： 装饰器实现修饰对象（Component）的接口，所有请求都转发给它处理，在转发请求之前/之后增加额外功能。使用步骤是： 用一个Decorator实现/继承需要修饰的对象Component； 在Decorator中增加一个Component的引用； 在Decorator的构造器中，增加一个Component参数来初始化Component； 在Decorator类中，使用Component的引用，将所有请求转发至Component的相应方法；

　　今天我们来学习一下装饰者模式。作为一名程序猿，相信许多人都跟我一样，在平时写代码的过程中，习惯使用继承。但是继承有时候会出现非常严重的问题，不过，没担心。装饰者模式将会给爱用继承的我们一个全新的设计眼界！ 一、星巴兹咖啡的故事 　　我们通过一个生动有趣的例子来引出我们今天的主角--装饰者模式。 　　 1、 现在呢，有一个咖啡馆，它有一套自己的订单系统，当顾客来咖啡馆的时候，可以通过订单系统来点自己想要的咖啡。他们原先的设计是这样子的： 　　 2、 此时、咖啡馆为了吸引更多的顾客，需要在订单系统中允许顾客选择加入不同调料的咖啡，例如：蒸奶（Steamed Milk）、豆浆（Soy）、摩卡（Mocha，也就是巧克力风味）或覆盖奶泡。星巴兹会根据所加入的调料收取不同的费用。所以订单系统必须考虑到这些调料部分。 　　下面是他们的第一次尝试： 　　这种设计肯定是不行的，简直分分钟把人逼疯的节奏，有木有！ 　　 3、 这时，有个人提出了新的方案，利用实例变量和继承，来追踪这些调料。 　　　　具体为：先从Beverage基类下手，加上实例变量代表是否加上调料（牛奶、豆浆、摩卡、奶泡……）， 　　 　　这种设计虽然满足了现在的需求，但是我们想一下，如果出现下面情况，我们怎么办， 　　　　①、调料价钱的改变会使我们更改现有代码。 　　　　②、一旦出现新的调料，我们就需要加上新的方法

场景引入： 　　小镇的咖啡馆生意越来越好了，但是来自不同地方的顾客也越来越多，有的人喜欢咖啡加糖，有的人喜欢咖啡加牛奶，有的喜欢加炼乳。。。 咖啡伪代码： class 咖啡{ void addSth(String param){ if(param.equals("糖")){ System.out.println("咖啡加糖。。。。"); }else if(param.equals("牛奶")){ System.out.println("咖啡牛奶。。。。"); } } } 每次出一种新品种，都要在if..else if..后添加，违反了对开闭原则的，对修改关闭的原则。 我们可以尝试以下策略模式来解决这个问题。 1.声明一个策略接口； 2.往后只要新增加一种口味，都生成一种新的具体策略实现类； 3.在生成咖啡时，将具体的策略赋值给咖啡，就可以生成不同口味的咖啡啦！ 是不是听起来很棒，那我们来看一下具体的代码实现吧 代码展示： 策略接口： //策略接口 interface Strategy{ void add(); } 加糖策略： //加糖策略 class SugarStrategy implements Strategy{ public void add(){ System.out.println("add Sugar...."); } } 加牛奶策略： //加牛奶策略 class