jueves, 2 de agosto de 2012

SRP: Single Responsibility Principle THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.


I want to show you  how SRP helps us to deal with the requirement and with the  requirement  changes. 
This is a real life problem I encountered in my work.

1)
The Idea is to build a WindowServices that runs somes processes in backGound.
There are 7 processes each one has its own hour to run and it is set from the database.

The first implementation was this:
We have a timer that polls the database each 5 minutes and checks if the process should run.
The process excecution is serial.




















2) The next change we were asked to do was to run processes in paralell, then the Services Class had  to be modified



















3) Next the services were installed in 3 nodes and now we could have a sincronitalization problem, then the Services Class had to be modified to fix it.




We noticed that "services class" had at least two differents responsibilities, one is To check the timer and the other one is to checks if the process should run.
In short we could add new functionalities such as Loggings, Exception Hangling and so on.
A better soluction  could have been to give the responsibility to check the process and run the process to another new class.It could be called ProcessDispatcher, and write new interfaces. 









Para ver otro ejemplo de este principio ver este el blog de NELO.











1 comentario: