AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Now the CFO wants to change the calculus of salary. This coupling can cause the actions of the CFO’s team to affect something that the HR team depends on. The save() method is specified by the database administrators who report to the CTO.īy putting the source code for these three methods into a single Employee class, the developers have coupled each of these actors to the others.The reportHours() method is specified and used by the human resources Department, which reports to the HR Director.The calculatePay() method is specified by the accounting department, which reports to the CFO.This class violates the SRP because those three methods are responsible to three very different actors. It has three methods: calculatePay(), reportHours(), and save() (Image 3). Let's take another example: “a single class for a more different actors” (taken from “Clean Architecture” by Robert Martin).Ĭonsider an Employee class from a payroll application. Single Responsibility Principle is now respected Each class of the new design has a single reason to change. and is also a package for letters) and Sender (knows the dispatching policy). There are three concepts: Letter (document), Envelope (deals with encoding, signature. Now we have divided the responsibilities into three separate classes (Letter, Envelope and Sender). Image 2: two solutions for modeling the Letter abstraction These are important design principles, not following them it can result in significant software maintenance costs (Image 1). So we should understand that the SOLID Principles are not some fancy good-to-have for our sw. So, the differences between following and not following the SRP could be a considerable financial impact!Īnd this applies not only to the SRP, but to all other SOLID principles as well. More time and more effort mean more money. This would require more time and more effort to be spent on re-testing the software after those changes are made, because we need to make sure we catch all the bugs before we release the modified version of the software. Every change to a software component opens the possibility of introducing bugs into the software. So, as there are frequent changes to a software component the probability of introducing bugs increase. If a software component has multiple reasons to change, then the frequency of changes it will increase. But what is the problem if our class has more reasons to change? So now we could rewrite the principle, “Every software component should have one and only one reason to change”. Why it is so important in software field that each component should have one and only one responsibility?īecause in place of the term responsibility we could put a new phrase “reason to change”. If we think of the Swiss Army Knife as a software component, it violates the Single Responsibility Principle, for the reason that it has multiple responsibilities. Although a Swiss Army knife is a versatile and highly regarded tool, the rules change when it comes to software. Why?īecause it's a metaphor, a Swiss Army knife is a combination of a number of useful tools, each with a distinct purpose like a mini scissor, screwdriver, and so on. So, component can be a class, a method or a module.Īs you can see, I have introduced this article with the image of a "Swiss Army Knife". But the term software component could also refer to a method or a function or even a module. When we say software component, if we are talking in the context of an object-oriented programming language, the first thing that comes to our mind is the class. The SRP says that “Every software component should have one and only one responsibility”. “S” in SOLID stands for Single Responsibility Principle, often abbreviated and referred to as “SRP”. Now it is time to start to talk about the first of five SOLID rules, the Single Responsibility Principle. In the last article I talked about Clean Architecture and SOLID Principles.
0 Comments
Read More
Leave a Reply. |