Timeline for Explanation on how "Tell, Don't Ask" is considered good OO
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 21, 2012 at 2:56 | history | edited | Matthew Flynn | CC BY-SA 3.0 |
deleted 23 characters in body
|
| Jul 21, 2012 at 2:54 | comment | added | Matthew Flynn | @LokiAstari - I think we're talking at cross purposes here--I was really looking at creating different systems, rather than different monitors. The thing is, the system should know when it is in a state that raises an alarm, as opposed to some outside controller function. SystemA should have its criteria, SystemB should have its own. The controller should just be able to ask (at regular intervals) whether the system is OK or not. | |
| Jul 20, 2012 at 23:40 | comment | added | Loki Astari | This is exactly why you should have a tell model. You tell the system the current conditions and it informs you if it is outside normal working conditions. Thus way you never need to modify the SystemMoniter. That's encapsulation for you. | |
| Jul 20, 2012 at 20:59 | comment | added | Matthew Flynn | @LokiAstari - You could, but then you could run into a new system that's also sensitive to humidity or atmospheric pressure. The principle is to abstract out what varies--in this case it is the susceptibility to overheating | |
| Jul 20, 2012 at 19:47 | comment | added | Loki Astari | Why not have each system register with the monitor. During registration they can indicate when overheating occurs. | |
| Jul 20, 2012 at 17:16 | history | answered | Matthew Flynn | CC BY-SA 3.0 |