书籍在线阅读链接：https://gpp.tkchu.me/design-patterns-revisited.html
书籍设计模式的unity实现的链接：https://zhuanlan.zhihu.com/p/39707078 很好的文章，简单的实现了该书的大部分设计模式
1，观察者模式
随便打开电脑中的一个应用，很有可能它就使用了MVC架构， 而究其根本，是因为观察者模式。
观察者模式应用广泛，Java甚至将其放到了核心库之中（java.util.Observer），而C#直接将其嵌入了语法（event关键字）。 难以置信的是，如此直观的东西是无数程序和应用框架交流的主心骨。
观察者模式是同步的。 被观察者直接调用了观察者，这意味着直到所有观察者的通知方法返回后， 被观察者才会继续自己的工作。观察者会阻塞被观察者的运行。
如果观察者列表存在触发的顺序关系，这意味着这两个观察者有一些微妙的耦合，最终会害了你。
但是如果耦合发生在观察者列表中，想要知道哪个观察者被通知到了，唯一的办法是看看哪个观察者在列表中，而且处于运行中。 你得理清它的命令式，动态行为而非理清程序的静态交流结构。
如果为了理解程序的一部分，两个交流的模块都需要考虑， 那就不要使用观察者模式，使用其他更加显式的东西。
观察者模式是一个让这些不相关的代码块互相交流(比如：成就系统，任何完全不相干的事物都可以达成成就)，而不必打包成更大的块的好方法。 这在专注于一个特性或层面的单一代码块内不会太有用。
如果设计今日的观察者模式，我会让它基于函数，而不是基于类。 哪怕是在C++中，我倾向于让你注册一个成员函数指针作为观察者，而不是Observer接口的实例。实现一整套接口只是为了接受一个通知不再符合今日的美学了。
个人感觉是：只要达到类似于观察者的通信形式，无论哪种写法都是可以的。
实现 https://blog.csdn.net/tran119/article/details/81166636 unity 消息发送机制
2，