Are SOLID principles really solid?

Question

The first pattern stands for this acronym is SRP. Here is a quote.

the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

That's is simple and clear till we start to code ) Suppose we have a class with well defined SRP. To serialize this class instances we need to add special atrributes to that class. So now the class have other responsibility. Dosen't it violate SRP? Let's see other story. Interface implementation. Then we implement an interface we simply add other responsibility say dispose its resorces or compare its instances or whatever. So my question. Is it possible to keep SRP complete? How can we do it?

Answer 1

I don't think that being serializable or disposable amounts to multiple responsibilities.

Answer 2

As you will one day discover, none of the most known principles in software development can be 100% followed.

Programming is often about making compromises - abstract pureness vs. code size vs. speed vs.efficiency.

You just need to learn to find the right balance: not let your application fall into abyss of chaos but not tie yourself hands with multitude of abstraction layers.

Answer 3

Well I suppose the first thing to note is that these are just good Software Engineering principles - you have to apply judgment also. So in that sense - no they are not solid (!)

I think the question you asked raises the key point - how do you define the single resposibility that the class should have?

It is important not to get too bogged down on details when defining a responsibility - just because a class does many things in code dosn't mean that it has many responibilities.

However, please do stick with it though. Although it is probably impossible to apply in all cases - it is still better than having a single "God Object" (Anti-Pattern) in your code.

If you are having problems with these I would recommend reading the following:

• Refactoring - Martin Fowler: Although it is obviously about refactoring, this book is also very helpful in displaying how to decompose problems into their logical parts or resposibilities - which is key to SRP. This book also touches on the other principles - however it does it in a lot less academic way than you may have seen before.

• Clean Code - Robert Martin: Who better to read than the greatest exponent of the SOLID principles. Seriously, I found this to be a really helpful book in all areas of software craftsmanship - not just the SOLID principles. Like Fowler's book, this book is pitched at all levels of experiance so I would recommend to anyone.

Answer 4

The thing to remember about design principles is there's always exceptions, and you wont always find that your scenario/implementation matches a given principle 100%.

That being said, adding attributes to the properties isn't really adding any functionality or behavior to the class, assuming your serialization/deserialization code is in some other class. You're just adding information about the structure of your class, so it doesn't seem like a violation of the principle.

Answer 5

I think there are many minor, common tasks a class can do without them obscuring the primary responsibility of a class: Serialisation, Logging, Exception Handling, Transaction Handling etc.

It's down to your judgement as to what tasks in your class constitute an actual responsibility in terms of your business/application logic, and what is just plumbing code.

Answer 6

To better understand the SOLID principles you have to understand the problem that they solve:

Object-oriented programming grew out of structured/procedural programming--it added a new organizational system (classes, et al) as well as behaviors (polymorphism, inheritance, composition). This meant that OO was not seperate from structured/procedural, but was a progression, and that developers could do very procedural OO if they wanted.

So... SOLID came around as something of a litmus test to answer the question of "Am I really doing OO, or am I just using procedural objects?" The 5 principles, if followed, means that you are quite far to the OO side of the spectrum. Failing to meet these rules doesn't mean you're not doing OO, but it means its much more structural/procedural OO.

Answer 7

By changing your definition of "single responsibility" - SOLID principles are quite liquid and (like other catchy acronyms of acronyms) don't mean what they seem to mean.

They can be used as a checklist or cheat sheet, but not as complete guidelines and certainly not learning material.

Answer 8

There's a legitimate concern here, as these cross-cutting concerns (serialization, logging, data binding notification, etc.) end up adding implementation to multiple classes that is only there to support some other subsystem. This implementation has to be tested, so the class has definitely been burdened with additional responsibilities.

Aspect-Oriented Programming is one approach that attempts to resolve this issue. A good example in C# is serialization, for which there is a wide range of different attributes for different types of serialization. The idea here is that the class shouldn't implement code that performs serialization, but rather declare how it is to be serialized. Metadata is a very natural place to include details that are important for other subsystems, but not relevant to the testable implementation of a class.