学习资料：

• 大话设计模式

1.简单案例

公司要发给程序员奖金，但老板没有说具体的时间，只说发之前会给通知，两个程序员便开始了漫长的等待

抽象Subject主题：

public interface Subject<T> {
    void notifys();／／通知
    void add(T t);//添加员工
}

具体的Subject主题：

public class Boss implements Subject<Employee>{

    private List<Employee> eList = new ArrayList<>();

    @Override
    public void notifys() {
        //eList.forEach((employee) -> employee.upDate());
        System.out.println("老板 --> 奖金已发");
        for (Employee employee : eList){
            employee.upDate();
        }
    }

    @Override
    public void add(Employee employee) {
        eList.add(employee);
    }

}

抽象的Observer观察者：

public abstract class Observer {
    protected String name;／／员工名字
    protected Subject subject;//主题，被观察者

    public Observer(String name, Subject subject) {
        this.name = name;
        this.subject = subject;
    }

    public abstract void upDate();
}

具体的观察者：

public class Employee extends Observer{

    public Employee(String name, Subject subject) {
        super(name, subject);
    }

    @Override
    public void upDate() {
        System.out.println(this.name +" --> "+ "收到！！！");
    }
}

测试：

public class ObserverTest {
    public static void main(String[] args) {
        //老板
        Boss boss = new Boss();
        //员工
        Employee employee1 = new Employee("程序员1号",boss);
        Employee employee2 = new Employee("程序员2号",boss);

        boss.add(employee1);
        boss.add(employee2);

        boss.notifys();
    }
}

运行结果：

老板 --> 奖金已发
程序员1号 --> 收到 ！！！
程序员2号 --> 收到 ！！！

2.特点

使用观察者的动机：

将一个系统分割成一系列相互协作的类有一个很不好的副作用，需要维护相关对象间的一致性。不能为了维护一致性而使各类紧密耦合，若紧密耦合，必定会导致维护、扩展和重用都非常不便

观察者模式的关键对象是： 主题Subject，观察者Observer ，一个Subject可以任意数目的依赖它的Observer，一旦Subject的状态发生了改变，所有的Observer都会得到通知。而Subject发出通知时，不需要知道具体的观察者是谁，同样任何一个观察者也不需要知道其他的观察者

应用场景：当一个对象的改变需要同时改变其他对象，并且这个对象不知道具体有多少对象有待改变

观察者模式所做的工作主要就是在解除耦合。一个抽象模型有两个方面，其中一个方面依赖于两一个方面，这时使用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。而观察者模式可以让耦合的双方都依赖于抽象，而不是依赖于具体的对象。从而使得各自的变化都不会影响另一边的变化

观察者模式是依赖倒置原则非常好的体现

2.1依赖倒置原则

依赖倒置原则：抽象不应该依赖细节，细节应该依赖抽象

• 高层模块不应该依赖低层模块，两个都应该依赖抽象
• 抽象不应该依赖细节，细节应该依赖抽象

将电脑理解为一个大型的软件系统的话，CPU，内存，硬盘，显卡可以理解为程序中封装的类或者程序集

电脑里这些元件也很容易拆卸插拔更换，也充分展现了高内聚，低耦合的特点。内存条坏了坏内存条，不用管显卡，各自的职责明确，也体现了单一职责原则。硬盘不够时，也可以暂时使用外接移动硬盘，体现了开放-封闭原则

全世界生产CPU的只有那么几家，而CPU却可以在千千万的的电脑主板上使用，在于CPU对外提供了针脚或者触点式的接口标准，外部无需知道CPU内部到底拥有怎么的高度精细程度，直要留出CPU的插槽就可以

无论CPU还是显卡等，对外都是针对接口设计，这也体现了依赖倒置原则，通俗点说就是 针对接口编程，而不是针对实现进行编程

电脑的设计虽然比收音机要复杂些，但由于电脑设计上除了具有高内聚，低耦合的特点，还有其他的一些设计模式原则的体现，很多时候都比收音机要易于修理维护。收音机属于典型的耦合过度，很多时候随便出一个毛病，往往都涉及其他的部件，并不一定比电脑维修简单

依赖倒置可以说是面向对象设计的标志，用哪种语言来编写不重要。编写程序时考虑到如何针对抽象编程而不是针对细节编程，也就是说程序中所有的依赖关系都是终止于抽象类或者接口，就是面向对象的设计，反之就是过程化设计

3.JDK中的Observable

2017年05月11号 22:06补充

在JDK中实现了一套观察者模式，使用挺方便的,可以直接拿来用

java.util.Observable是被观察者，继承就可以，通过notifyObservers()方法来通知观察者
java.util.Observer是观察者，是一个接口，实现后，重写upDate()方法，来实现接到通知后的处理逻辑

模拟LOL中简单的打龙场景，LOL玩的不多，勉强算青铜5的水平，不过已经弃坑了，没啥时间玩

3.1 被观察者：纳什男爵

public class BaronNashor extends Observable {
    /**
     * 通知蓝方打野盲僧
     */
    public void notifyJungle() {
        int random = (int) (Math.random() * 2 +1);
        setChanged();
        notifyObservers(random);// 发出通知
    }
}

setChanged()方法用来改变被观察者的状态，之后才可以通知，否则无效

3.2 观察者：盲僧李青

public class Leesin implements Observer{

    @Override
    public void update(Observable o, Object arg) {
         if (arg instanceof Integer){
             int i = (int) arg;
             if (i % 2 == 0){
                 System.out.println("全体集合，来打男爵");
             }else {
                 System.out.println("猥琐发育，别浪。不打男爵");
             }
         }
    }
}

重点就是upDate()方法，来实现各种逻辑

测试代码

public class LoLTest {
    public static void main(String[] args) {
        BaronNashor baronNashor = new BaronNashor();
        baronNashor.addObserver(new Leesin());// 添加观察者
        baronNashor.notifyJungle();
    }
}

结果：

猥琐发育，别浪。不打男爵

观察者可以添加多个，也可以移除观察者，还有其他的方法

4.最后

接下来打算继续学习RxJava，就先对观察者模式学习了解

本人很菜，有错误请指出

共勉 ：）