学习到现在的主要问题是没有进行例子的完美历练，说白了，就是没动手亲自的试试，写写对应的代码，理解一下主要的设计思想，这个应该是学习设计模式我最重要的地方，那么现在针对之前学习的设计模式做一个总结和回顾吧
0.设计模式分析规律
在讲解这个设计模式之前，我们应该学习到设计的原则，1.分析程序中变化的位置，针对变化的位置进行封装隔离
分析是对鸭子的叫声和会飞进行了特殊的隔离，因为这两种行为是特殊于其他普通鸭子的行为，这里考虑的就是封装这个变化
第一种角度：我们考虑之前的行为都是采用继承的关系，但是这样所有的子类都具有叫声和飞行的行为了，不能这样用
第二种角度：我们采用接口的形式，让父类实现这两个接口，其他子类进行覆盖，有的鸭子就覆盖，没有就不覆盖，这样的写法带来的问题是，以后要是有新的行为加入进来，子类和父类还要修改
引入第二个设计原则：针对接口编程，而不是实现编程
那么这样考虑以后，有了另一种角度
第三种角度：设计两个接口，一个叫，一个飞行，然后写各自的实现类，叫声类，和飞行类，将这两个类的接口行为组合在鸭子的父类中，即鸭子父类持有这两个行为接口，
父类写两个方法，使得有些鸭子可以请求叫方法，有的可以请求飞行的方法，让子类来传递飞行和叫的方式，比如:有的“呱呱叫” 有的不叫，有的飞行有的像火箭一样
为了实时修改这两个类，加入设置的set方法动态修改叫和飞行的行为
问题：这里父类也有了叫和飞行的行为，是不是违背了之前说的不用继承，特殊行为应该在某些子类上
问题：这里要考虑我们之前说的变化是什么？1，叫和飞行的行为区别于一般鸭子，只是这样的一种，2.叫和飞行的行为有一类这样的行为了
1.策略设计模式
上面的例子貌似是特意为策略设计模式制定的，那么我们该怎么样分析这个模式
算法簇的替换，而不影响其他的行为
模式结构：一个接口，多个实现类，用这个接口来维护一种或多种行为，不同的实现类相互替换（非典型的策略模式）
//飞行接口
public interface FlyBehavor{
void fly();
}
//飞行行为类
public RebotFly implements FlyBehavor{
public void fly(){
//添加自身的非行为
}
}
public class Duck{
private FlyBehavor mFlyBehavor;
public Duck(FlyBehavor mFlyBehavor){
this.mFlyBehavor = mFlyBehavor;
}
public void performFly(){
mFlyBehavor.fly();
}
}
思考:
1.典型的策略模式的结构和适用场景
策略模式典型是Context（场景），Strategy(接口策略)，策略子类，场景对接口策略进行持有，利用子类替换达到不同算法的目的
适用场景:用同一个方法，来计算不同的业务关系，制定不同算法
2.适用构造方法传参，还是适用setter方式，有什么区别，各有什么优缺点？
构造方法在初始化定义传入参数，setter方式是改变当前对象的持有属性，setter用于一个对象多次改变自身属性
2.状态模式
状态模式是对象通过改变自身的属性，来改变其行为（方法），达到消除条件判断语句的作用
状态模式的结构重点：
ContextState(对象场景)，State（对象持有状态属性），状态子类，状态子类和策略子类的区别就是状态子类通过方法传递入参ContextState来修改本身状态
1 public class ContextState{
2 public State mState;
3 public int hour;//状态属性
4 public void setState(State state){
5 mState = state;
6 }
7 public void request(){
8 mState.handle(this)
9 }
10 }
11
12 public interface State{
13 void handle(ContextState state);
14 }
15
16 public StateA implement State{
17 public void handle(ContextState context){
18 //这里用来改变当前对象的状态
19 context.state = new StateB();
20 if(context.hour < 12){
21 //上午工作很充实
22 }else{
23 //不符合条件继续向下分发
24 context.setState(new StateB());
25 context.request();
26 }
27 }
28 }
29 public StateB implement State{
30 public void handle(ContextState context){
31 //这里用来改变当前对象的状态
32 context.state = new StateA();
33 if(context.hour < 12){
34 //上午工作很充实
35 }else{
36 //不符合条件继续向下分发
37 context.setState(new StateA());
38 context.request();
39 }
40 }
41 }
以上代码仅供参考
思考：
1.状态模式必须有相应的状态属性吗？这种状态可以用枚举来代替吗？
2.状态模式适用的场景有哪些，是通过什么样的出发点来使用状态模式的？
状态模式的出发点就是对象本身状态的改变来修改行为，那这种状态可以是多个吗？
3.观察者模式
相关例子的引入是做一个气象发布器，将系统发布的气象信息显示在多个公告栏上
多个公告栏的实时更新是核心部分，变化的位置是在哪里?比如添加或减少一个信息公告栏，信息公告栏的主要功能变化，公告栏的外观的变化，发布信息的数据结构变化（接入其他系统的气象信息）
之前的设计方式是否合理，这个是根据OO设计经验来完成的，要多积累才行
之前的设计是在气象更新器中写死气象信息更新的类，有信息更新，就发送给公告栏，这样的设计有什么问题吗？
问题1.如果多个公告栏中有一个不用了，这样我们要手动删除代码，测试，
问题2.气象加入了新的公告信息，加入新的字段，比如温度，湿度，风向，级别
问题3.OO设计思想是什么？为什么要这样用？
问题1.违反了OO设计原则：对扩展开发，对修改关闭
问题2.将所有的类统一成一个整体
问题3.设计类交互的松耦合而努力
模式结构：
"推"消息
被观察者（气象站） 观察者（公共栏）
拥有对所有观察者的引用（集合） 提供一完整的更新接口（update）
信息更新（遍历，将气象信息传递给公共栏）
-----------------------------------------------------------------------------------
"拉"消息
被观察者（气象站） 观察者（公共栏）
拥有对所有观察者的引用（集合） 提供一完整的更新接口（update（obseverable,obj）
信息更新（遍历，将气象信息传递给公共栏）
观察者模式主要的结构
一个被观察者，多个观察对象，当被观察者改变时通知其他观察对象作出改变（一个对象内部状态改变的同时通知其他对象改变）
被观察者拥有观察者的集合，并且拥有添加和移除，通知方法，观察者有抽象的更新数据接口
思考：
1.怎样实现一个对象既是观察者也是被观察者，在Java中有系统库可以实现吗？
2.观察者模式适用的场景有哪些？
4.装饰模式
作用：对一个对象已有功能动态的添加更多功能的一种方式
优点：有效的区分类的核心功能和装饰功能，在特殊时间或特定时期给核心功能添加部分装饰
代码结构：
一个通用的装饰接口，装饰类及其子类，
//接口
public interface Compent{
void Operation();
}
//装饰类
public Decorate implement Compent{
protected Compent mCompent;
public void setCompent(Compent compent){
mCompent = compent;
}
public void Operation(){
mCompent.Operation();
}
}
//装饰类的子类
public DecorateA extends Decorate{
private String msg;
public void Operation(){
//添加文案输出功能
System.out.println(msg);
super.Operation();
}
}
//特殊情况下，装饰类和装饰子类可以进行合并