At some point in our career, we have all written code that we considered good, but needed full code replacement later on, even though the functional change requested was very small. When this occurs, it is often an indication of lack of either understanding or correct application of the SOLID principles.

Several years ago, I attended a talk on the principles, and it prompted me to try to be more aware of applying them to my code. From this I learned several lessons, the most important one being that almost no one takes the time to determine if they apply them at all, let alone correctly. It caused me to add an additional iteration to all my coding and code-review in which I actively ask the question: “Is it SOLID?”

But simply knowing the SOLID principles is not enough; you need to understand the why and how as well, which are actually a lot harder. These are important as the principles themselves are somewhat open for interpretation, which complicates applying them significantly. In this talk, I won’t focus on each of the principles themselves, but I’ll use examples of breaking two of the lesser understood ones and the problems this causes to highlight the reason why SOLID development is so important.

Comments

Comments are closed.

Max Roeleveld at 14:20 on 30 Jun 2017

A more detailed look at two of the SOLID principles. Not a beginner's overview.

An indepth talk with some good insights.
Tips: Try to speakup a bit more flowing english. And also give some examples of hou you should do it.

Great talk

Anonymous at 16:10 on 30 Jun 2017

Jip Spinnewijn at 16:41 on 30 Jun 2017

Very interesting talk with clear examples. I did not really understand the problem with the abstract factory though and final classes should be no problem when mocking interfaces instead of concrete classes ?

Jeroen v.d. Gulik at 17:39 on 30 Jun 2017

Interesting talk but I have to say I disagree with a lot of the examples. Specifically the Dependency Inversion examples didn't seem to actually be about dependency inversion. I missed examples about Dependency Injection, and more specifically about trade-offs when to apply SOLID principles

Youri Thielen at 19:27 on 30 Jun 2017

To be honest, I expected more from this talk. A few things I would like to point out:
- Dependency Injection Principle was used where Dependency Inversion Principle was meant. They are related but not the same.
- When you talked about the open/closed principle, focus was a lot on the PHP language keyword 'extends'. The "open for extension" part of the open/closed principle is actually about the concept of changing a class'/module behaviour, this can be done trough extending a class but composition should be preferred. "Composition over inheritance" was not mentioned.
- The Liskov examples were pretty much spot on
- The examples regarding DIP were not that great to be honest. They missed the essence of the DIP principle. Also, the examples could have been a lot simpler.
- There are good reasons to use the final keyword in PHP. Also, don't mock what you don't own (regarding your complaint about not being able to mock a Doctrine class)
- Suggesting not to use the private keyword was not backed by a good reason.

Erik de Bos at 21:44 on 30 Jun 2017

I expected a more in depth evaluation of SOLID, with practical examples. Instead this was a rather basic walk-though of the principles.

I agree with Youri Thielen's comment.
In addition, you somewhere mentioned about using @throws annotations that it does not matter whether you name a specific type or just 'Exception'. In my opinion, this is not a very good idea. If an exception is annotated by its exact type, it can be caught by exactly that type (assuming that the one who writes a corresponding try/catch clause looks at the @throws annotation). In that way, you don't have the risk of catching exception you did not expect (in contrast to the situation when using 'Exception' or 'Throwable' in your catch clause.)

To end on a more positive note: somewhere in the talk you mentioned that 'you should not be using the "extends"-keyword too much', and I can only agree to that.

Pulkit Swarup at 23:23 on 30 Jun 2017

Talking about SOLID Principles and choosing the right examples to explain the principles is a really tricky.

Although, the presentation started on a right note picking up principles which are least understood and discussed, but there is a reason i.e. the right examples and that was precisely which was missing.

Peter Meijer at 15:44 on 1 Jul 2017

I was expecting a different talk based on the title. Not a 'recap' of SOLID.

Deniz Zoeteman at 20:38 on 1 Jul 2017

Okay talk, was interesting to hear these opinions, and I agree on some points. However, it would have been nice to have some solutions given to the problems talked about.+

Niels van Esch at 09:45 on 3 Jul 2017

a solid (pun intended) talk on some of the less understood parts of SOLID. It had a few misunderstandings of the finer details of the the principle in it, but these were negligible. Talk was given with good energy

Vladas Dirzys at 10:59 on 3 Jul 2017

The presenter looked confident. Also I think it's good idea not to talk about every SOLID principle in depth but only about the chosen ones. However, the given examples didn't make much sense. In addition on how not to do it, the presenter could have had examples of how to do it.

I had serious doubts if the presenter really understands the DIP (and others). I would like to look at the examples and try to analyse them again, but can't find the slides.

I'm not a guru, but that were parts that actually I'm afraid of those who took you seriously, like
- fixing bugs by extending
- final keyword is bad
- don't use private variables (really?)
- cannot mock Doctrine due to the way they do the Query object
(rule of thumbs, don't mock what you don't own, make integration tests for the parts that touch plugins/libraries/bunbles/... and then mock those services for your own code)

It was a nice overview with emphasis on the two less understood principles. I was expecting a bit more examples and experience based on the title though.