3 ms·
Going down this path seems to put your code at risk for dangerous mixing of concerns, in some cases. Unit-testing the check_for_overheating inside SystemMonito
by 0x0 14y ago
Going down this path seems to put your code at risk for dangerous mixing of concerns, in some cases.
Unit-testing the check_for_overheating inside SystemMonitor looks complicated... The "sound_alarms" call inside probably needs to be a reference to a "Speaker.sound_alarms", right? Why should the SystemMonitor be locked to the API of a Speaker? etc.
- unconed 14y agoThe 'sound_alarms' call looks more like a local method to me, which could invoke the speaker in a loosely coupled fashion. The point is more about putting the behavior itself in the object. For unit testing, you'd want to move the individual tests into their own classes, letting the SystemMonitor be the glue that calls them and routes responses to the appropriate system.
- 0x0 14y agoYour second sentence pretty much hit the nail on the head, as I was reading your first: I'd create a different "controller" object that glues the SystemMonitor and the Speakers together. Then you'd have the neat little "tell, don't ask" in THAT object, instead. (Pretty much what you suggested)