关于观察者模式

有时候就是脑子莫名会想些之前的事。

之前面试的时候被问到观察者模式，我的回答是：我们下单时有做短信通知，是通过MQ的方式通知的，这里在小项目中也能替换成观察者模式。
面试官：这边调用一个短信通知函数不就好了，为什么要用观察者模式
我：直接调用的话两个模块会强依赖，而且后续有新的通知比如说报表模块通知，那又要去改下单的代码，而使用观察者模式可以直接注册到观察者队列就行，不用改原代码。

我有时也会想这样做是不是多此一举，明明加一行代码的事，非得弄个观察者模式。
其实主要的原因是所有代码都是对我们开发者开放的，我们想改就改，为了方便就不会太在意设计模式的使用。
观察者模式是遵循了设计模式中的开闭原则的，对代码解耦。举个例子，每个模块或者类都是一块私人空间，就像你家一样，如果你家没有门，别人想进就进，想干嘛就干嘛，你会有安全感吗。代码也是，没有安全感也就谈不上稳定性，这也是对修改关闭的原因。但是现在的开发模式所有的代码都是对开发者开放的，谁都能改，就像你家装了一个门（规矩），但是没上锁，别人来不来你家闹全看他心情。

代码也是有上锁的方式的，所有的模块独立作为一个工程模块，模块间相互可以引用使用，对于业务开发人员只开放他对应的开发模块，其他他不可见的模块可以打包上传到私有maven仓库，模块可以从仓库下载到对应的引用模块的jar包，这种方式开发人员想改都改不了。如果这时候下单模块设计了观察者模式，使用者会感觉相比改源码这个设计模式使用的很方便。

尤其是common这种公共模块，源码其实不应该开放出来给业务开发者。

PS：感觉MQ替换成观察者模式的说法不对，他们并不是一个东西，MQ虽然也是以解耦为目的但是它还能提供消息安全的异步能力，只是它的调用代码还是写在订单逻辑里的，设计方面如果使用观察者模式，在观察者中实现MQ的短信通知会更方便扩展其他通知。不过这个具体要看业务，不然会存在过度设计的问题，例如上面下单的例子本身就不是很好，实际并不会有模块引用订单模块，而订单模块本身就是一个业务模块，本身并不应该这样过度的设计，还是要以开发效率为主，直接使用MQ是在分布式架构下比较好的方案，单体的小项目则直接调用，当然如果真的有3个以上的通知，而且后续可能还有，还是设计上观察者模式比较好。