S.O.L.I.D principles and compilation?

Question

For example , regarding Single Responsibility principle :

Let's talk about a Radio class :

enter image description here

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 :

enter image description here

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"

Radio's single responsibility is to model a radio. If the original intent behind Single Responsibility was to fragment your code by turning classes into functions, that's the dumbest idea in the history of C#/Java OOP shenanigans. I'm getting the sense somebody took a sensible idea, ran way too far with it, and way too many people listened. This is dumber than beans / getters/setters all over the damn place. Why do people have such a hard time with OOP? — Erik Reppen, Dec 23 '12 at 11:48
@ErikReppen I dont know about people , I know about me. I saw this thing with this compile mentioned and wanted to know - why ? how ? — Royi Namir, Dec 23 '12 at 12:08
I know it wasn't your idea. I'm just frustrated with the notion that anybody would advocate breaking an object's domain into pieces like this completely unnecessarily because of yet another stupid acronym or YASA if you will. — Erik Reppen, Dec 23 '12 at 12:14
I 100% agree with Erik. Also, if you were to apply SOLID, you cannot do it piecewise. You apply it as a whole. So in your case, if it was really necessary to separate radio in such a way, you would use Dependency Inversion thus creating abstractions for changing volume and station and put implementations in separate modules. — Euphoric, Dec 23 '12 at 13:38

score 11 · Answer 1 · edited Apr 11 '17 at 01:33

11

Forget compile time, Forget application restart.

SOLID is about clean code and maintainability. It is not about anything at runtime, it's about the code getting more complicated over time and hard to maintain, and that is where the real cost is.

edited Apr 11 '17 at 01:33

Sergey

1,608
1
27
40

answered Dec 23 '12 at 08:28

TomTom

61,059
10
88
148

I wanted to forget but again, they always mention "the compilation stuff". It must have something to do with it. – Royi Namir Dec 23 '12 at 08:29
1

I think you need to specify what you mean by _they_ - in the articles I read about SOLID aI never saw compilation concerns mentioned. – flq Dec 23 '12 at 08:32
http://epic.tesio.it/doc/manual/solid_principles.html look for the word "recompiled" – Royi Namir Dec 23 '12 at 08:33
http://www.gontu.org/solid-single-responsibility-principle/ look for the word "build" – Royi Namir Dec 23 '12 at 08:35
Do yourself a favour and get some decent book on the Topic. Those blog entries seem at least to give you a wrong Focus. He is merely MENTIONING it. Most of These things are no really relevant in a properly set up Environment (unit tests, Impact Analysis etc.) – TomTom Dec 23 '12 at 10:08
1

The "compilation stuff" is another way of stating dependencies. If the interface of the volume manager hasn't changed, just the implementation, then you only need to compile the volume manager. In other words, the radio class only depends on the volume manager's interface (its methods and properties) and not on its implementation. You could swap it out for another volume manager (that provides the same interface) without having to compile the radio (ignoring a couple of other constraint depending on your chosen language). – Marjan Venema Dec 23 '12 at 11:03
In theory, but in the real world that means that in order to only compile the manager, every manager must be a separate dll. Say hello to projects of 4000+ dll files - you are in another world of hell. This looks a LOT better in C++ where the compilation goes into library "temporary" files for the linker, but in C# I would fire any idiot who thinks that having a separate project and dll for simple items like that is a good solution. Managing the codebase (thousands of pretty much empty projects) is another item this sucks. Reality does not conform to the delusions of ivory tower architects. – TomTom Dec 23 '12 at 11:29
In this particular case, you really talk about comments made for C++ - slow compiles, separate linker process. They are of limited usability in C# which follows a different compilation and deployment paradigm. – TomTom Dec 23 '12 at 11:34

score 7 · Accepted Answer · edited Dec 23 '12 at 15:05

7

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.

edited Dec 23 '12 at 15:05

Royi Namir

144,742
138
468
792

answered Dec 23 '12 at 08:46

jalf

243,077
51
345
550

2

@TomTom: where did I say every class should go in a separate dll? That is your interpretation. I just said that if you only have to update one DLL, then you have a very concrete way to see the scope of your changes (nothing outside that DLL was recompiled, so none of it has changed, and none of it can have broken). I have absolutely no idea what your point is with unit tests and impact analysis, or why you imply that I don't use either. – jalf Dec 23 '12 at 10:56
2

But since you brought up unit tests, here's some news for you: tests can never show the absence of an error. Only its presence. You can spend the rest of your life writing unit tests, and it won't prove that your code change didn't break anything. But if you don't touch the code at all, if the customer can keep using the same DLL they used in the previous version, then they have proof positive that no new bugs have been introduced. Some clients care about that, whether or not you do. Deal with it. – jalf Dec 23 '12 at 10:59

score 3 · Answer 3 · answered Dec 23 '12 at 09:02

Compilation time is not an issue in C# compared to C++. A big C++ project might take ages to compile. It becomes really frustrating when trying to make a change in one area causes recompilation of unrelated components. Single responsibility guides towards more compact dependencies in that way improving a compilation problem.

score 3 · Answer 4 · answered Dec 23 '12 at 09:56

I highly recommend Uncle Bob's clean coders videos on SOLID principles.

The main idea behind independent deployability, is that modules that can be independently deployed can also be independently developed. Usually you don't independently deploy modules, but you do benefit from being able to independently develop them.

Related to the effects on the compilation process, this is probably relevant in C++ where each compilation unit ( cpp file ) will need to be recompiled when code it depends on changes and where a carefully constructed dependency graph, where a change impacts only one compilation unit, can seriously affect the compilation time. Anyway, unless you are working on older hardware, you should probably not make compile time a priority.

About having to stop the app ( web or console ) when an independent module is modified and deployed - this can be avoided by using a plugin framework, that can dynamically load new/changed assemblies into the app - and SOLID principles can be applied to the way you build the plugins and their interfaces. Keep in mind that this might add more complications, and I would recommend avoiding this and just restarting the app on deployment.

score 2 · Answer 5 · answered Dec 23 '12 at 08:28

I don't think the saved compilation is what matters, rather why you could get away without it.

Because a certain change is contained in a limited area of your app. This is a good thing in itself - in a well-designed system I don't have to understand the complete application in order to change its behavior and I think that's what matters.

The fact that dlls are locked or the IIS restarts the affected App-Pool (which it does pretty well I might say) are technicalities that may be mitigated in some future system.

Indeed, with some shadow-copying and App-Domain hokey-pokey you can write a program which you wouldn't need to restart when you exchange a dll.

score 1 · Answer 6 · answered Dec 23 '12 at 08:40

I think that important thing to bare in mind with design patterns is flexibility. If you once decide to implement various types of StationManager and VolumeManager, you will have to change no code in your Radio class. The only change will be imposed by the instantiation of the class Radio. For this you will still have to restart your application, but you will not have any spaghetti code in your class, with multiple if-else statement. No code will change, you will just add new code for the new classes. This also obeys another important Design principle: the open/closed principle (the O in SOLID): code should be open for extension, but not for modification. Even though you follow all the good design practices, you still have to restart your app so that the changes take place

So why to mention the compilation thing ?. I already know what solid helps me with. — Royi Namir, Dec 23 '12 at 08:43

score 0 · Answer 7 · answered Dec 23 '12 at 15:51

Actually arguments related to compilation and build process are not really important to .NET platform. But it can be very important to some other platform or/and languages.

For example, in C++ world this benefit can lead to dramatic productivity boost by dev team, because it will save hours during compilation time. In C++ world using Bridge Pattern or Pimpl idiom can save a lot of time, because every change in header file (even in private part) will lead to recompilation for all dependencies (direct or indirect). In this case build or compilation aspect of SOLID principles can be really beneficial.

Long story short: SOLID principles are not about build process or recompilation, its all about dependencies. But when you manage your dependencies properly you'll definitely gain in those areas as well (including, but limiting build and compilation processes).

S.O.L.I.D principles and compilation?

7 Answers7