设计模式学习心得

学习到现在的主要问题是没有进行例子的完美历练，说白了，就是没动手亲自的试试，写写对应的代码，理解一下主要的设计思想，这个应该是学习设计模式我最重要的地方，那么现在针对之前学习的设计模式做一个总结和回顾吧

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来修改本身状态

  public class ContextState{
     public State mState;
     public int hour;//状态属性
     public void setState(State state){
         mState = state;
     }
     public void request(){
       mState.handle(this)
    }
  }

   public interface State{
    void handle(ContextState  state); 
  }
  
  public StateA implement State{
    public void handle(ContextState context){
      //这里用来改变当前对象的状态
       context.state = new StateB();
         if(context.hour < 12){
              //上午工作很充实
         }else{
              //不符合条件继续向下分发
               context.setState(new StateB());
              context.request();
        }
       }  
   }  
  public StateB implement State{
    public void handle(ContextState context){
      //这里用来改变当前对象的状态
       context.state = new StateA();
         if(context.hour < 12){
              //上午工作很充实
         }else{
              //不符合条件继续向下分发
               context.setState(new StateA());
              context.request();
        }
       }  
   }         

以上代码仅供参考

思考：

 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();
  }
}
//特殊情况下，装饰类和装饰子类可以进行合并