Hi folks,
At my current work, as a part of a program to learn and improve our skills as a developer, we pick a good book related to software engineering, read a chapter each week and discuss with the team on what we learnt, how it can be useful to the team.
Currently we are reading the book, Adaptive Code: Agile coding with design patterns and SOLID principles. We have been reading the book for some time, and the challenge we face right now is that none of us use C# at the work. We have mobile, web and systems teams and we primarily use java, swift, javascript and C. Language wise, it was a bad choice to pick this book; However the book is pretty good and well organized.
In Mobile team, we don't have any challenges in following the examples as C# & Java are OOP oriented. But our web team have challenges to grasp the concepts as they write in javascript (angularjs and node.js) which is functional oriented.
This is one good link that I found out,
Have anyone come across any other good examples, references, or books that you can recommend?
Also I would like to understand what SOLID principles means to a web developer who's writing in angularjs & node.js and how they can apply. Can anyone throw some light on this.
Top comments (7)
You have attributed the difficulty in following SOLID principles to Javascript being "functional oriented". However, I believe the difficulty translating the concepts to JS is actually because JS is dynamically typed. In dynamic languages, Liskov and Interface Segregation can be mostly ignored due to "duck typing". (Like all principles I'm sure this is arguable, especially because JS has prototypal inheritance. But just because it's there doesn't mean you have to use it.) Conversely, you need to have tests to verify assumptions about objects, which may (or may not) have otherwise been covered by typing.
Here is a slide deck I found about SOLID principles in Angular, although it is for an older version. It also uses TypeScript, but the only type annotations I saw were on strings, so it is basically still dynamic ES6.
SOLID Principles in Angular
Here is a pretty simple overview of what SOLID principles looks like in Ruby, also a dynamic language.
SOLID Principles in Ruby
Thank you Kasey!!.
I understand your point.
Appreciate for sharing the information!!
In dynamic languages, Liskov and Interface Segregation can be mostly ignored due to "duck typing"
Also, I have the feeling that the Liskov substitution principle is a rather outdated point. Back in the days inheritance was the thing in OOP, but now most devs try to avoid it and use aggregations anyway.
SOLID.
Single responsibility principle - applicable to JavaScript.
Open/closed principle - JavaScript excels at this.
Liksov substitution principle - duck typing of JavaScript makes this easy to do. But you need TDD-style unit tests to make this robust.
Interface segregation principle - duck typing makes this not much of an issue.
Dependency inversion principle - duck typing, again, makes this easy to do. Still have to DO IT, though... low coupling, high cohesion.
After having used functional programming languages, JavaScript is not a functional programming language. ES6 is a few inches closer to being one, but still has a mile to go.
Great write-up! Also wrote some thoughts about it but in context of Go. Although Golang is not a purely object-oriented language, we can still apply SOLID principles to improve our Go code - packagemain.tech/p/mastering-solid...
Does the program at your work seem to be effective? Does everyone have their own book, and does everyone share every week?
Hi Johnny,
We are a small team of 15 people with varying years of experience in the industry in different technologies. Some are 15-20 years experienced and some are on their first job.
The program is fully supported by the company, so the cost of books is reimbursed. The books are chosen by the team via voting. So far, we have finished close to 4-5 books.
When we talk about effectiveness, most of the team attend regularly, but number of people who share each week varies. Most often the cause for this was due to the nature of the book/chapter. As I explained in the discussion, People who aren't familiar or actively writing OOP programming finds it harder to read and share about the concepts.
We encourage everyone to participate, but it's not mandatory. The idea of the program is to provide a platform where the team can improve their skillset/development practices, but it's up the individual to take advantage of it.
So far from what I have seen, most of the team have taken advantage of the program. And as a result of it, we do see several fruitful discussions happening about the development practices in the team.