![]() ![]() We are the ones who decide to change how the employee state is persisted: Maybe we want to migrate from stored procedures to an ORM or even swap out an SQL database for a non-SQL one. Saving Employee state falls within the responsibility of the IT department of the business. Save() is probably the easiest to determine the actor for: It’s us – software developers and DBAs. Who are the actors that Employee‘s public methods are responsible to? Therefore GetRegularHours() is used by both CalculatePay() and ReportHours(). The developers were careful and kept the code DRY (Don’t Repeat Yourself). Martin uses the following Employee class to demonstrate a typical SRP violation:Ĭlass Employee has three public methods (+ signs): In his excellent book, ‘ Clean Architecture‘, Robert C. Violating the SRP and its Effects – An Example Given that terms like stakeholders don’t relate directly to programming, Martin falls back to the UML term ‘Actor’.Ī better definition for the Single Responsibility Principle would then beĮach module should only be responsible to one actor. He made the point that the SRP is concerned with responsibilities to people, or better, a group of people or stakeholders. Martin, claims that this principle is not about each module having only a single responsibility per se. What about a reason to change ? The ‘discoverer’ of the SRP, Robert C. In some procedural languages, modules may be as simple as files containing functions that belong together (e.g. In object-oriented programming (OOP) languages, modules are classes (e.g. Reading this definition, a couple of questions come to mind:Ī module is a mid-level programming construct combining functions with data structures. The Single Responsibility Principle states thatĮach module should only have a single reason to change. The S in SOLID represents the Single Responsibility Principle (SRP). SOLID is an acronym made up from the initial letters of the five principles that compose it. We are continuing from yesterday’s article on the purpose of the SOLID Principles. Classes are made up of internal data structures and exposed functions that act on those data structures. Classes have more moving parts than mere functions. Yet the SOLID Principles operate at the level of the class, not the function. Indeed, that rule exists, but it’s not the Single Responsibility Principle!įunctions should do only one thing. Again and again, I hear developers complaining that this principle is being violated because some function does more than one thing. We’ve got SOLID’s Single Responsibility Principle all wrong.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |