这里面综合了几本书的资料.
需求有这么个项目:
需求是这样的:
一个气象站, 有三个传感器(温度, 湿度, 气压), 有一个WeatherData东西, 它能从气象站获得这三个数据. 还有三种设备, 可以按要求展示气象站的最新数据.
WeatherData的布局如下:
有3个get要领, 分袂获取最新的气温, 湿度和气压. 还有一个measurementsChanged()要领, 当任一传感器有变革的时候, 这个要领城市被挪用.
总结一下项目的需求:
WeatherData类有三个get要领可以获取温度, 湿度和气压
如果任何一个数据产生变革, 那么measureChanged()要领就会被挪用
我们需要实现这三种显示设备:
当前天气
数据统计
天气预测
系统必需可以扩展, 其他开发者可以创建自界说展示设备.
第一版代码
这个处所有个"错误", xxxDisplay都是具体的实现, 而编程法则要求是应该对接口编程而不是对实现编程.
那么什么是不雅察看者模式?举一个例子:
报社刊行报纸
你订阅报纸, 一旦有新一期的报纸刊行, 新报纸就会送到你家里, 只要你一直订阅, 你就一直会收到新报纸
你不再订阅报纸的时候, 就收不到以后的新报纸了
报社运营的时候, 一直会有人去订阅或者打消订阅报纸.
颁布者 + 订阅者 = 不雅察看者模式
Publishers + Subscribers = Observer Pattern
在不雅察看者模式里, 我们把报社叫做被不雅察看东西(Subject), 把订阅者叫做不雅察看者(Observers)
不雅察看者模式是这样操纵的:
不雅察看者模式的界说就是:
一个方针物件打点所有相依于它的不雅察看者物件，，并且在它自己的状态转变时主动发出通知。
类图如下:
当两个东西是松耦合的时候, 他们可以进行交互, 但是却几乎不了解对方.
不雅察看者模式下的被不雅察看者(Subject)和不雅察看者(Observers)就是松耦合设计的东西. 这是因为:
被不雅察看者(Subject)只知道不雅察看者实现了某个接口
可以随时添加不雅察看者
添加新类型不雅察看者的时候不需要改削被不雅察看者
可以复用不雅察看者或者被不雅察看者
如果被不雅察看者或不雅察看者产生变革了, 那么这些变革不会影响到对方.
一个设计原则:交互的东西之间应尽量设计成松耦合的. Strive for loosely coupled designs between objects that interact.
松耦合设计可以让我们设计出这样的系统: 因为东西之间的彼此依存减小了, 所以系统可以轻松措置惩罚惩罚变革.
代码:
OK, 上面是书中的内容, C#7.0里面对不雅察看者模式是怎么实现的呢?
先只谈下面这个:
Event谈到Event, 就得把delegate先细说一下
Delegate 委托一个委托类型界说了某种类型的要领(要领的返回类型和参数类型), 然后这个委托的实例可以挪用这些要领.
例如:
delegate int Transformer (int x);
这个委托就和返回类型是int, 参数是一个int的要领兼容.
例如: