Timeline for Single Responsibility Principle - How Can I Avoid Code Fragmentation?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 11, 2014 at 16:52 | comment | added | supercat | If instead those functions were combined into an IKiln interface, which was implemented by a Kiln object, then the TemperatureFeedbackSystem would only need to hold a single IKiln reference. If it was necessary to use a kiln with an independent aftermarket temperature sensor, one could use a CompositeKiln object whose constructor accepted an IHeaterControl and ITemperatureSensor and used them to implement IKiln, but such deliberate loose composition would be easily recognizable in code. | |
| Oct 11, 2014 at 16:49 | comment | added | supercat | A related issue I've not seen discussed is that if tasks that are tied to one logical entity get fragmented among different classes, then it may be necessary for code to hold references to multiple distinct objects which are all tied to the same entity. Consider, for example a kiln with functions "SetHeaterOutput" and "MeasureTemperature". If the kiln were represented by independent HeaterControl and TemperatureSensor, objects, then nothing would prevent a TemperatureFeedbackSystem object from holding a reference to one kiln's heater and a different kiln's temperature sensor. | |
| Mar 12, 2014 at 19:34 | comment | added | dj18 | +1 for "does every change only affect one class?" | |
| May 30, 2012 at 3:58 | history | answered | pdr | CC BY-SA 3.0 |