网上写设计模式的文章也是比较多了，笔者分享下自己对观察者模式的理解和实现，如有不足还请指出。
观察者模式的基本概念：这个其实比较好理解，观察者模式中两个重要的角色，一个是观察者，一个是被观察者。比如A是被观察者，我们给A一个观察者B，那么A有什么动作，比如收到了什么消息，做了什么，那么作为观察者的B也会做出自己的响应。
观察者模式的实现：
1.定义一个观察者接口类，并且定义一个方法
2.创建一个这个接口类的实现类，也就是我们具体的观察者类，并且将接口类中定义的update方法进行实现。在这里多句嘴，笔者觉得接口类和实现类的关系，就好比是点菜和做菜的关系。先是点了菜，我要吃红烧肉，然后实现类去做菜了，而做菜的师傅，是可以有不同的，红烧肉的做法，也是可以多样的。张三师傅做了甜口的红烧肉，李四师傅做了咸口的红烧肉。而为什么我们说要面向接口编程而不是面向实现编程呢，好处就在于扩展性和解耦性。扩展性和解耦度的问题，在本篇文章最后会有阐述，这里我们先继续完成我们的观察者模式代码。
3.创建一个被观察者类，这里笔者的起名很土，直接就是拼音，开发中这么写肯定会被批评，但是本篇的目的在于分享思想，所以类名的问题，就先不讨论了。重点说一下这个被观察者类，你会发现，通篇没有使用到我们的观察者实现类，也就是observeImpl类，而是用的观察者的接口类observe，这里其实是多态的一个思想，父类引用指向子类实现。观察者可以有多个，并且有各自的不同的update方法的实现，本次就写了一个例子，就是打印message。笔者这里举一个例子，比如说有个被观察者，他的功能是做满汉全席，而观察者呢则是各个菜系的厨师，这时候满汉全席类收到了消息：“开始做满汉全席！”，之后各个观察者，也就是各个菜系的厨师，就都开始做自己的菜系了。放到我们的业务逻辑中也是一个道理，观察者的使用，笔者觉得主要也是在这里。代码也大概说一下吧，12行是添加一个观察者进来，16行是删除一个观察者。观察者的添加和删除，意味着这个观察者要和被观察者有绑定关系，这个关系就是通过第8行的List容器实现的，也就是这个类的一个公共属性。20行是遍历我们的观察者list并且调用观察者的方法。26行是我们的被观察者被操作了，这里的被观察者就是将入参和类的公共属性messge做了一个赋值操作，如果有被观察者的具体业务逻辑，也是写在这里就。
4.编写测试代码，将各个部分使用起来的样子。整个逻辑的是没问题的，当被观察者收到一个消息的时候，观察者会做出相应的一个动作。网上很多分享，是将被观察者的notifyMethod这个方法给单独拿出来再调用了，笔者个人觉得（个人觉得哈），这种是不对的，等于是我们的被观察者收到了消息，而我们的观察者想要做出相应的响应的话，还需要额外的去通知观察者。 就拿kafka来举个例子，生产者是被观察者，消费者是观察者。当生产者有数据来了，消费者会直接去broker上拉取消息来消费，而不需要我们有别的什么操作了。所以笔者觉得，从使用的角度上来看，观察者模式的“通知方法”也就是本文中的notifyMethod，并不应该单独抽出来并进行调用。
回顾本文第二条中，这种父类引用指向子类实现的方法，扩展性和解耦度，是体现在哪里呢？就好比我们的被观察者中的通知方法，也就是notifyMehtod方法，目前我们是只有一个Observer接口类的实现，而我们可以有多个对于Observer接口类的实现，但是notifyMethod方法，是不用去修改的了，这里体现的，就是一个扩展性。而对于解耦呢，解的到底是什么呢，解的是需求和实现。再举回我们点菜做菜的例子，洪福餐厅的菜单上有一道红烧肉，之前是张三师傅做的，但是过了一阵，老板发现张三的红烧肉不行，让李四去做。客人点菜依旧是点的红烧肉，说明需求没有变化，但是实现却改变了，因为张三和李四做的红烧肉是截然不同的（假设截然不同）。而总结一下以上这个过程，需求没有变，而实现改变了，说明菜单我们是不用去变的了，如果失去解耦这个过程，那就是菜单上写的是张三红烧肉，红烧肉换人做了，就得把菜单改成李四红烧肉，意味着什么，意味着又有额外的工作需要去做。而我们的软件开发工作，就是存在一个很明显的点，那就是常态化的改变，需求朝令夕改笔者相信大家也都是有经历过的，少改，省时省力还能少出错，这就是扩展和解耦的意义所在。
网友评论