设计模式——解释器模式
解释器模式1、四则运算问题通过解释器模式来实现四则运算，如计算a+b-c的值，具体要求
1）先输入表达式的形式，比如a+b+c-d+e，要求表达式的字母不能重复。
2）在分别输入a，b，c，d，e的值。
3）最后求出结果。
【传统方案解决四则运算问题】1）编写一个方法，接收表达式的形式，然后根据用户输入的数值进行解析，得到结果。
2）问题分析：如果加入新的运算符，比如*/（等等，不利于扩展，另外让一个方法来解析会造成程序结构混乱，不够清晰）。
3）解决方案：可以考虑使用解释器模式，即：表达式——>解释器（可以有多种）——>结果。
2、解释器模式基本介绍【1】解释器在编译原理中，一个算术表达式通过词法分析器形成词法单元，而后这些词法单元再通过语法分析器构建语法分析树，最终形成一颗抽象的语法分析树。这里的词法分析器和语法分析器都可以看作是解释器。
【2】解释器模式解释器模式（Interpreter Pattern）：是指给定一个语言（表达式），定义它的文法的一种表示，并定义一个解释器，使用该解释器来解释语言中的句子（表达式）。
在解释器模式中，我们需要将待解决的问题，提 ...
设计模式——状态模式
状态模式1、APP抽奖活动问题1）假如每参加一次这个活动要扣除用户50积分，中奖概率是10%。
2）奖品数量固定，抽完就不能抽奖。
3）活动有四个状态：可以抽奖、不能抽奖、发放奖品和奖品领完。
2、状态模式基本介绍1）状态模式（State Pattern），它主要用来解决对象在多种状态转换时，需要对外输出不同的行为的问题，状态和行为是一一对应的，状态之间可以相互转换。
2）当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。
【状态模式原理】1）Context类为环境角色，用于维护State实例，这个示例定义当前状态。
也称为上下文，它定义了客户程序需要的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
2）State是抽象状态角色，定义一个接口封装与Context的一个特定接口相关行为。
3）ConcreteState具体的状态角色，每个子类实现一个与Context的一个状态相关行为。
3、应用实例代码实现123456789101112131415161718192021222324252627282930313233343 ...
设计模式——中介者模式
中介者模式1、天气预报项目需求1）智能家庭包括各种设备，闹钟、咖啡机、电视机、窗帘等。
2）主人要看电视时，各个设备可以协同工作，自动完成看电视的准备工作，比如流程为：闹铃响起->咖啡机开始做咖啡->窗帘自动落下->电视机开始播放。
【普通解决方案】闹钟类发送消息给咖啡机类，咖啡机类启动后通知窗帘类，窗帘类落下后通知TV类。
【方案问题分析】1）当各电器对象有多种状态改变时，相互之间的调用关系会比较复杂。
2）各个电器对象彼此联系，你中有我，我中有你，不利于松耦合。
3）各个电器对象之间所传递的消息（参数），容易混乱。
4）当系统增加一个新的电器对象时，或者执行流程改变时，代码的可维护性、扩展性都不理想，所以要考虑使用中介者模式。
2、中介者模式的基本介绍1）中介者模式（Mediator Pattern），用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。
2）中介者模式属于行为型模式，使代码易于维护。
3）比如MVC模式，Controller是Model和View的中介者，在前后端 ...
设计模式——自定义SpringIOC
自定义SpringIOC现在要对下面的配置文件进行解析，并自定义Spring框架的IOC对涉及到的对象进行管理。
1234567<?xml version="1.0" encoding="UTF-8"?><beans> <bean id="userService" class="com.itheima.service.impl.UserServiceImpl"> <property name="userDao" ref="userDao"></property> </bean> <bean id="userDao" class="com.itheima.dao.impl.UserDaoImpl"></bean></beans>
1、定义bean相关的pojo类【1】Proper ...
设计模式——自定义SpringIOC，BeanFactory接口分析
Spring IOC相关接口分析1、BeanFactory解析Spring中Bean的创建是典型的工厂模式，这一系列的Bean工厂，即IOC容器，为开发者管理对象之间的依赖关系提供了很多便利和基础服务，在Spring中有许多IOC容器的实现供用户选择，其相互关系如下图所示。
其中，BeanFactory作为最顶层的一个接口，定义了IOC容器的基本功能规范，BeanFactory有三个重要的子接口：ListableBeanFactory、HierarchicalBeanFactory和AutowireCapableBeanFactory。但是从类图中我们可以发现最终的默认实现类是DefaultListableBeanFactory，它实现了所有的接口。
那么为何要定义这么多层次的接口呢？
每个接口都有它的使用场合，主要是为例区分在Spring内部操作过程中对象的传递和转化，对对象的数据访问所做的限制。
例如：
ListableBeanFactory接口表示这些Bean可列表化。
HierarchicalBeanFactory表示这些Bean是有继承关系的，也就是每个Bean可能有父B ...
设计模式——观察者模式
观察者模式1、天气预报项目需求1）气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去（比如发布到自己的网站或第三方）。
2）需要设计开放型API，便于其他第三方也能接入气象站获取数据。
3）提供温度、气压和湿度的接口。
4）测量数据更新时，要能实时通知给第三方。
【普通解决方案】1）通过对气象站项目分析，我们可以初步设计一个WeatherData类。
2）WeatherData类中提供了getTemperature、getHumidity、getPressure、dataChange等方法。
3）通过getXxx方法，可以让第三方接入，并得到相关信息。
4）当数据有更新时，气象站通过调用dataChange()去更新数据，当第三方再次获取时，就能得到最新数据，当然也可以推送。
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970// 显示当前天气情况public c ...
设计模式——迭代器模式
迭代器模式1、学院展示需求编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系。
【传统方式问题分析】1）将学院看作是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的。
2）实际上我们的要求是：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系，因此这种方案，不能很好实现遍历的操作。
3）解决方案：迭代器模式。
2、迭代器模式的基本介绍1）迭代器模式（Iterator Pattern）是常用的设计模式，属于行为型模式。
2）如果我们的集合元素是用不同的方式实现的，有数组，还有java的集合类，或者还有其他方式，当客户端要遍历这些集合元素的时候就要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式解决。
3）迭代器模式，提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构。
3、结构
抽象聚合（Aggregate）角色：定义存储、添加、删除聚合元素以及创建迭代器对象的接口。
具体聚合（Concret ...
设计模式——访问者模式
访问者模式1、测评系统需求1）将观众分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价（评价有不同的种类，比如成功、失败等）
2）传统方案
Person为父类，Man和Woman继承Person类。对Man和Woman分别进行判断
3）传统方案问题分析
如果系统比较小，还是ok的，但是考虑系统增加越来越多新的功能时，对代码改动较大，违反了ocp原则。
扩展性不好，比如增加了新的人员类型，或者管理方法，都不好做。
2、访问者模式的基本介绍1）访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
2）主要将数据结构与数据操作分离，解决数据结构和操作耦合性问题。
3）访问者模式的基本工作原理是：在被访问的类里面加一个对外提供接待访问者的接口。
4）访问者模式主要应用场景是：需要对一个对象结构中的对象进行很多不同操作（这些操作彼此没有关联），同时需要避免让这些操作“污染”这些对象的类，可以选用访问者模式解决。
3、结构1）抽象访问者（Visitor）角色 ...
设计模式——命令模式
命令模式1、智能生活项目需求1）我们买了一套智能家电，有照明灯、风扇、冰箱、洗衣机，我们只要在手机上安装app就可以控制这些家电工作。
2）这些智能家电来自不同的厂家，我们不想针对每一种家电都安装一个App，分别控制，我们希望只要一个app就可以控制全部智能家电。
3）要实现一个app控制所有智能家电的需要，则每个智能家电厂家都要提供一个统一的接口给app调用，这时就可以考虑使用命令模式。
4）命令模式可将“动作的请求者”从“动作的执行者”对象中解耦出来。
5）在我们的例子中，动作的请求者是手机app，动作的执行者是每个厂家的一个家电产品。
2、命令模式的基本介绍1）命令模式（Command Pattern）：在软件设计中，我们经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计。
2）命令模式使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活，实现解耦。
3）在命令模式中，会将一个请求封装为一个对象，以便使用不同参数来表示不同的请求（即命令） ...
设计模式——模板模式
0、行为型模式行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。
行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足”合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。
行为型模式分为：
模板方法模式
策略模式
命令模式
职责链模式
状态模式
观察者模式
中介者模式
迭代器模式
访问者模式
备忘录模式
解释器模式
以上11种行为型模式，除了模板方法模式和解释器模式是类行为型模式，其他的全部属于对象行为型模式。
模板模式1、豆浆制作问题1）制作豆浆的流程：选材 => 添加配料 => 浸泡 => 放到豆浆机打碎
2）通过添加不同的配料，可以制作出不同口味的豆浆
3）选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的
4）请使用模板方法模式完成（因为模板方法模式比较简单，很容易就想到这个方案，因此就直接使用，不再使用传统的方案来引出模板 ...