For example , regarding Single Responsibility
principle :
Let's talk about a Radio
class :
One could argue that the Radio
class has two responsibilities, being volume and station management. These operations will be called from completely different areas of the client using it.
hence we have this :
All fine.
But I always see sentences like these :
So now when we need a change , all the code depending on the broken component don’t even need to be recompiled.
Wait a minute !
If I need to change the VolumeManager
class - I will not have to recompile Radio
and StationManager
.
But I will have to stop ( in web) the iis in order for the application to use the new DLL, and it will cause the application down.
Also , in console
, I will have to terminate the whole program in order to change the dll since it is locked by the process ( you cant change dll when the app is running - the file is locked)
even when I'll use the GAC - I will have to stop the proram in order to chagne the dll.
so what does it save me ? compile is just - right click and build. thats all
I'm not seeing the benefit of mentioning : "you will need to compile only the broken class.."
What Am I missing ?
http://www.gontu.org/solid-single-responsibility-principle/ look for the word "build
"
http://epic.tesio.it/doc/manual/solid_principles.html look for the word "recompiled
"
http://www.dananhudson.com/?tag=solid look for the word "recompile
"
There are situations where it is "politically" easier to deploy an update to an existing application if you can show that the changes are limited in scope: if only one DLL has to be updated, for example. (note that this does not mean that every class should be in its own DLL. But most likely, not all your classes are in the same DLL)
However, the other advantage is more conceptual: if I don't have to recompile a DLL, then I know for sure that I didn't break anything in it. The less code has to be touched, the less chance there is of me introducing a bug.