grzesiek-galezowski / tdd-ebook

Test-Driven Development - Extensive Tutorial. Open Source ebook
https://leanpub.com/tdd-ebook
Other
361 stars 57 forks source link

Is BroadcastingObserver really more flexible? #93

Closed mradecki closed 5 years ago

mradecki commented 7 years ago

Regarding fragment:

Another, more flexible option, is to use something like we did in the previous chapter with a HybridAlarm (remember? It was an alarm aggregating other alarms) – i.e. instead of introducing a collection in the sensor, we can create a special kind of observer – a “broadcasting observer” that would itself hold collection of other observers (hurrah composability!) and broadcast the values to them every time it itself receives those values

I might be very picky I wouldn't say that this option is more flexible. Notice that with this approach user needs to decide which observers are going to be used in the system up front. Registering additional observers later is not possible - I wouldn't call that flexible at all.

I am thinking of scenario, where I could subscribe to such TemperatureSensor working as a web service. Let's say I am calling some kind of method through web API, and after that I am opening socket on given address and start to listen. Now I expect to periodically receive message written in some kind of a protocol containing mean temperature and current temperature.

So, I imagine, that on server's side, new let's say.. RemoteObserver is created and it subscribes to the TemperatureSensor object:

remoteObserver = RemoteObserver(socket=...) temperatureSensor.FromNowOnReportTo(remoteObserver)

I don't expect to be exclusive recipient of this data. I just want to subscribe.

With BroadcastingObserver approach this whole scenario is not possible, because list of receivers is set during creation o TemperatureSensor and cannot be modified later.

I was thinking of moving FromNowOnReportTo method from TemperatureSensor to broadcastingObserver, but that would break the Observer interface.

grzesiek-galezowski commented 7 years ago

Thanks for this catch, indeed, this part is poorly stated. What I had in mind is that if you extract the notification mechanism outside the sensor, you get to implement it however you want, including publication/subscription. In such case, the broadcasting observer might have the registration method as well. I agree that the FromNowOnReportTo method on the sensor would not be needed. One way or another, this needs to be corrected.

By the way, now that I think of it, the flexibility in both cases is exactly the same - even if we leave the loop inside the sensor, we can still create and register a broadcasting observer as a single element in that collection and we get the same effect.

grzesiek-galezowski commented 7 years ago

Hopefully i fixed it in the latest release. I also did some other small changes. Anyway, the changes are in chapter "How does a sender obtain a reference to a recipient" - please take a look.