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.
Continue reading SOLID principles by examples: open/closed
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.
Continue reading SOLID principles by examples: single responsability
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:
||Single Responsability Principle
||A class should have only a single responsability.
||Open Closed Principle
||Software entities should be open for extension but closed for modification.
||Liskov Substitution Principle
||Objects in a program should be replaceable with instances of theri subtypes without altering the correctness of that program.
||Interface Segregation Principle
||Many client-specific interfaces are better than one general purpose-interface.
||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.
Continue reading UWP Prism Unit Test