This post continues the analisys of the SOLID principles started some blog posts ago. This is the turn for the Open Closed Priciple (OCP).
An object/entity should be open for extension but closed for modification.
What we are basically talking about is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code.
This blog post will explain with simple examples the Singe Responsabily Principle of SOLID agiles principles to better understand how we can improve our daily coding activites. In future post I’ll cover the other four priciples.
A class should have only one reason to change.
Defined by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices it is the first of the five SOLID agile principles. What it states is very simple, however achieving that simplicity is not so obvious.
Agile@school by Alessandro Alpi è un progetto per portare nelle scuole i principi di lavoro agile e moderne concezioni di organizzazione del lavoro in un team di sviluppo software.
Pare che ci sarà la possibilità di organizzare la stessa cosa anche presso l’ITIS di Rovigo dove c’è la specializzazione informatica con la partecipazione del sottoscritto. Non vedo l’ora!
All the good things come to an end, right? And this is true also for Agile@School 2017. However, no worries, although I’m becoming a dad, I’m pretty sure I’ll keep making the students more aware of the Agile principles and practices.
There are only good news, to be honest. The first one is that Michele Ferracin, a friend of mine at getlatestversion.it community, is starting to keep in touch with schools (we really don’t know how many of them will participate) in order to start Agile@School also in Padova. “Bring the project in two cities”, perk reached! The second news is about the students this year. Everything is set up and running. Everyone is ready. Each team has chosen how to present the results to the exam’s board:
The Messinesi team (Amanda and Alex) has prepared a Prezi presentation, whose goal is to depict the…
View original post 234 more words
SOLID is a common acronym in the software development world. It’s useful to remeber five best practices to design classes in a object oriented language. It means:
|
Initial |
Stands for |
Concept |
| SRP | Single Responsability Principle | A class should have only a single responsability. |
| OCP | Open Closed Principle | Software entities should be open for extension but closed for modification. |
| LSP | Liskov Substitution Principle | Objects in a program should be replaceable with instances of theri subtypes without altering the correctness of that program. |
| ISP | Interface Segregation Principle | Many client-specific interfaces are better than one general purpose-interface. |
| DIP | Dependency Injection Principle |
One should depend upon abstractions, not concretions. |
These concepts are easy to understand when we read them, but what does it mean to apply them in our daily coding activities? What do we have to do?
In the next posts we’ll go through each concept with coding examples because as someone much smarter than me said:
Tell me and I’ll foget, show me and I might remember. Involve me and I will remember. – Confucius
I’m sure we all hear about unit testing, test driven development and so on. These practices are useful and provide a long list of benefit like writing low-coupled and mantainable code to name a few.
We want to write unit test for our UWP Prism application and we’d like, for example, to put our ViewModels under tests to make sure the logic they implement is correct. Unit testing is possible only if we can get rid of all the dependencies in our class under test because we want to run our test every time we want (for exemple when the service library our teammate is writing is not yet finished) and as fast as we can.
