设计模式学习心得，设计模式
学习到现在的主要问题是没有进行例子的完美历练，说白了，就是没动手亲自的试试，写写对应的代码，理解一下主要的设计思想，这个应该是学习设计模式我最重要的地方，那么现在针对之前学习的设计模式做一个总结和回顾吧
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();
}
}
2.观察者模式
相关例子的引入是做一个气象发布器，将系统发布的气象信息显示在多个公告栏上
多个公告栏的实时更新是核心部分，变化的位置是在哪里?比如添加或减少一个信息公告栏，信息公告栏的主要功能变化，公告栏的外观的变化，发布信息的数据结构变化（接入其他系统的气象信息）
之前的设计方式是否合理，这个是根据OO设计经验来完成的，要多积累才行
之前的设计是在气象更新器中写死气象信息更新的类，有信息更新，就发送给公告栏，这样的设计有什么问题吗？
问题1.如果多个公告栏中有一个不用了，这样我们要手动删除代码，测试，
问题2.气象加入了新的公告信息，加入新的字段，比如温度，湿度，风向，级别
问题3.OO设计思想是什么？为什么要这样用？
问题1.违反了OO设计原则：对扩展开发，对修改关闭
问题2.将所有的类统一成一个整体
问题3.设计类交互的松耦合而努力
模式结构：
"推"消息
被观察者（气象站） 观察者（公共栏）
拥有对所有观察者的引用（集合） 提供一完整的更新接口（update）
信息更新（遍历，将气象信息传递给公共栏）
-----------------------------------------------------------------------------------
"拉"消息
被观察者（气象站） 观察者（公共栏）
拥有对所有观察者的引用（集合） 提供一完整的更新接口（update（obseverable,obj）
信息更新（遍历，将气象信息传递给公共栏）