When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function.
Similarly it will be the COO’s organization that will request changes to the reportHours method, and the CTOs organization that will request changes to the save method.Īnd this gets to the crux of the Single Responsibility Principle. So it stands to reason that when changes are made to the algorithm within the calculatePay method, the request for those changes will originate from the organization headed by the CFO. If the enterprise database were to be corrupted by such a horrific mis-specification, the CTO would likely be fired. So if there were a catastrophic mis-specification of that report, the COO would be fired.įinally, it should be obvious which of the C-Level executives would be fired if there were a catastrophic mis-specification of the save method. That executive manages the auditors and reviewers, and that’s an operations responsibility. If all the employees were paid double for a year because someone in the CFOs organization mis-specified the rules for calculating pay, the CFO would likely be fired.Ī different C-Level executive is responsible for specifying the format and content of the string returned from the reportHours method. Specifying the pay of employees is a financial responsibility. Now, which of those C-Level executives reporting to the CEO is responsible for specifying the behavior of the calculatePay method? Which of them would be fired by the CEO if that method were catastrophically mis-specified? Clearly the answer is the CFO. The reportHours method returns a string which is appended to a report that auditors use to ensure that employees are working the appropriate number of hours and are being paid the appropriate compensation.The ‘save’ method stores the data managed by the Employee object onto the enterprise database.The calculatePay method implements the algorithms that determine how much a particular employee should be paid, based on that employee’s contract, status, hours worked, etc.And the CTO is responsible for the technology infrastructure and development within the company. The COO is responsible for managing the operations of the company. The CFO is responsible for controlling the finances of the company. Reporting to that CEO are the C-level executives: the CFO, COO, and CTO among others. But if that is the case, what is the program responsible for? Or, perhaps a better question is: who is the program responsible to? Better yet: who must the design of the program respond to? Those things are the responsibility of the programmer, not of the program.
#Single responsibility principle functions code
These questions can be answered by pointing out the coupling between the term “reason to change” and “responsibility”.Ĭertainly the code is not responsible for bug fixes or refactoring. Others have wondered whether refactorings are reasons to change. Some folks have wondered whether a bug-fix qualifies as a reason to change. However it begs the question: What defines a reason to change? This sounds good, and seems to align with Parnas’ formulation. The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. (I have this vague feeling that I stole the name of this principle from Bertrand Meyer, but I have not been able to confirm that.) In the late 1990s I tried to consolidate these notions into a principle, which I called: The Single Responsibility Principle. During that time the notions of Coupling and Cohesion were introduced by Larry Constantine, and amplified by Tom DeMarco, Meilir Page-Jones and many others. Structured Programming and Design were all the rage.
The 1970s and 1980s were a fertile time for principles of software architecture. in which he introduced the term: The Separation of Concerns. Two years later, Edsger Dijkstra wrote another classic paper entitled On the role of scientific thought. Parnas’ conclusion was that modules should be separated based, at lease in part, on the way that they might change. I added the emphasis in the second to last sentence. We propose instead that one begins with a list ofĭifficult design decisions or design decisions which are Of a system into modules on the basis of a flowchart. It is almost always incorrect to begin the decomposition “We have tried to demonstrate by these examples that The paper is fascinating reading, and I strongly urge you to study it. In this paper, Parnas compared two different strategies for decomposing and separating the logic in a simple algorithm. It appeared in the December issue of the Communications of the ACM, Volume 15, Number 12. Parnas published a classic paper entitled On the Criteria To Be Used in Decomposing Systems into Modules.
0 kommentar(er)
