![]() 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. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |