I've been struggling to grasp my head around the SRP pattern, because I dont know if it refers to a actor o to the use case.

In the following case:


To don't violate the SRP, would you need to create a class for every action (Maintain user, game, log on....) or a single Parent Teacher class?

  • 2
    SRP isn't a pattern, law or mandate; it is a principle. SRP doesn't really apply to actors or use cases; it applies to the use of classes to provide functionality. – Robert Harvey May 21 '18 at 19:58
  • "Game" does not look like a use case to me. "Play <specific name of a game>" might be one. And "Difficulty" - what strange kind of use case do you associate with that term? – Doc Brown May 21 '18 at 20:10

Firstly, you should describe the use case as a verb, because, it is an objective of the Actor's action.

Now on the SRP, when you are modeling your solution for SRP, you should reflect whether each member of the class is bound to it and if each line of code is actually on the method of could be delegated to another method.

Looking at your example, you will be in the SRP if you create the Question, User, and Game classes. The Logon action is a user method. The difficulty (I think it is a set of game difficulties) must be a member within the Game class.

In addition, you would like to create three other classes, for Teacher, Child and Parent. If the classes Teacher and Parent take the same responsibility, you can do a inheritance creating a class for Adult (you choose the name) which the Teacher class and Parent class will to extends.

I hope it was helpful to you, think about it and I wish you good code!


From Robert C. Martins book Clean Architecture: A Craftsman's Guide to Software Structure and Design, published September 10 2017, Robert writes on page 62 the following:

Historically, the SRP has been described this way:

A module should have one, and only one, reason to change

Software systems are changed to satisfy users and stakeholders; those users and stakeholders are the "reason to change". that the principle is talking about. Indeed, we can rephrase the principle to say this:

A module should be responsible to one, and only one, user or stakeholder

Unfortunately, the word "user" and "stakeholder" aren't really the right word to use here. There will likely be more than one user or stakeholder who wants the system changed in the sane way. Instead we're really referring to a group - one or more people who require that change. We'll refer to that group as an actor.

Thus the final version of the SRP is:

A module should be responsible to one, and only one, actor.

Today the SRP is about controlling the flow of requirements and business needs, which can only come from one soure. That source is the group of people (stakeholders and users) Mr Martin calls actor.

This means it has little do do with UML.


"Single Responsability" and "actor or use case" are independant of each other

usecase is from the enduser point of view: what should the app do (features, functionality)?

Single responsible priciple as a how is an implementation detail and an architectural topic from developper point of view.

spagetti code might be usefull for enduser to fullfill his requirements.

perfectly implemented code might be useless for an enduser if it does not full the requirements.


Software architecture is about modeling a domain of interest so that we can apply automation to some of the domain activities — automation such as storing & cataloging, automation such as search & retrieval, automation such as computation, calculation, and transformation.

SRP is about keeping various automated capabilities independent and loosely coupled, and suggests that we treat different responsibilities in separate modules or classes rather than conflating them together into a single module or class.

Our software designs often grow & evolve, sometimes because we learn more about the domain, other times as we expand the scope of the automation we're trying to provide.  During growth and evolution of a design, we may find that a single module has grown and is now addressing two separate responsibilities — so, we would then refactor to tease the independent responsibilities apart.

SRP and other design principles are just guidelines; don't let them stop you from trying things to making progress with design.  Software is soft after all, we can change it at will!

The illustration you're showing offers a list of concerns but these are not responsibilities; neither is this diagram a use case.  I would submit that you don't have enough detail about your domain or what you want software to do to help automate your domain, so concentrate on elaborating the domain and what you want automated support for, and don't worry about SRP for the moment.

Further, an action is not necessarily a responsibility as sometimes several actions pair together over a single responsibility.  Grading homework might be one responsibility; storing student grades another; delivering a report card another.  Though related these are separate responsibilities.  Storing grades also means being able to retrieving them as needed by other responsibilities, so there are multiple actions associated with this one responsibility.


You're looking at this from the wrong perspective. Maybe it helps if we use a real world analogy.

The company has 15 employees. They all get a wage, which is done by using the company accounting software.

The company decides to instruct all employees, so that each employee can do their own administration and have their wage paid (let's assume no stealing/malice). Everything works as intended.

The accounting tool has had an update, or the company has decided to use a different tool altogether. It takes a full day course to teach someone how to use the new tool. All 15 employees need to attend this course.

After a while, the company starts noticing problems with the accounting.

  • The company can't afford to have all of its employees unavailable for a day whenever there's an update to the software.
  • Not all employees are as good at math as the others. The ones that are bad at math are doing their best, but math really isn't their strong suit.
  • Some employees are filing the records alphabetically by first name. Other employees are filing them alphabetically by last name. Either option is fine, but because there are two different ways of doing things, people often can't find a file where they expect to find it. Both sides of this debate argues that the other group should change their approach, since their own approach is perfectly workable.

The company changes its approach. They hire a 16th employee ("the accountant"), who is responsible for paying the wages. And immediately, the benefits becomes clear:

  • Employees no longer have to take time out of their day to do administration, so they can focus on their actual job more.
  • When the software tool is updated, only the accountant needs to attend the full day course.
  • The accountant files things however he sees fit. Since no one else is doing the accounting, there is are no conflicting approaches.
  • The company hired an accountant with the adequate amount of math skill. When hiring an accountant, the company only needs to care about their accounting skills. They don't care if the accountant does or doesn't have other skills too (e.g. sales).
  • When hiring new non-accountant employees, the company doesn't need to ensure that they hire someone capable of doing basic accounting. Instead, they simply hire whoever is best at the core skill for the job.

The job of accounting is only done by the accountant.

There is something else to consider.

If the accountant would be doing multiple jobs (accounting, production, sales), he would need to attend courses for all three departments whenever a course was scheduled. This means that when he's out of office for an accounting course, he's unavailable to create products or sell them to customers; even though the jobs of producing/selling goods have not changed and do not require any training.
The more jobs he has, the more often he is unavailable for all of his jobs while he is in a course for one of his jobs.

This is bad. It's better to have three part-time employees (accountant, production staff, salesman) than it is to have one employee who has to juggle multiple jobs. It's harder to find the right employee with the right skillset, and each of their multiple responsibilities distract the employee from their other responsibilities.

The accountant should only do the job of accounting

Combining the two conclusions, we get to the SRP.

One actor is solely responsible for no more than one task.

Some examples of this:

  • I want logging in my application, across all the projects. However, it takes some effort to find the correct file to log to. So instead, I create a Logging project ("the accountant") whose sole job it is to take a message ("employee timesheet") and write the message to the appropriate destination ("pay the employee's wage").
  • I want to access my database in many parts of the code. However, it takes some effort to set up the connection and handle any possible errors. So instead, I create a Database project ("the accountant") whose sole job it is to provide simplified access ("account report") and internally handles the complex logic of getting the data ("generating the account report from the archive").

There is a common thread here: the existence of the single actor (accountant/logging project/database project) is only justified if they simplify the task at hand or enforce consistency. It's easier to ask someone to pay your wage than it is to do it yourself. It's easier to ask someone to log your message than it is to log it yourself.

If it takes five times longer to ask the accountant to do something than it does to do it yourself, and there's no issue with you doing it your own way, then you shouldn't hire that accountant.

Just for completeness' sake; I left out that the accountant does become a single point of failure. When he is absent from work, no one gets paid. In the old system where everyone paid their own wage, that wasn't an issue. However, the better solution here is to have a backup accountant (or an accounting department), rather than teaching every employee accounting.

In reality, the company might have too many employees for a single accountant to handle and you need to hire several accountants. However, this does not apply to software, you never need a second class which has identical code and behaves the exact same way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.