I have a class that represents a button on the screen. This class has two methods: one for click event; the other for long-click event. Both events do different things.

So, according to Single Responsibility Principle, a class must be responsible about one thing then must be only one thing that forces you to change the class. If each event is different, should I create 2 classes for each event?

In addition, does anybody has a complex example of this principle? I can only find the case of the Employee. It's easy understand, but I would like read one that is more complex.

  • 13
    If you assume that the buttons responsibility is to take in user input and call the appropriate method, then you aren't violating the SRP.
    – Ampt
    Oct 13, 2014 at 17:39
  • In practice, that button has lots of things to do. Like giving feedback if the user clicks on a button and moves the mouse outside and back inside, displaying some text, and taking actions when certain user inputs happen. It's single responsibility is "show an appropriate UI and call appropriate methods when the user takes certain actions".
    – gnasher729
    Apr 7, 2016 at 8:59

3 Answers 3


Most real world examples that I have found are either too simple or too complex to fully explain here. I would recommend looking at BlackWasp's articles on SRP. (Much of the content of that site can be summarized as shown below.)

From the man who created the term Single Responsibility Principle:

... This principle is about people.

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. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.

Why? Because we don't want to get the COO fired because we made a change requested by the CTO. Nothing terrifies our customers and managers more that discovering that a program malfunctioned in a way that was, from their point of view, completely unrelated to the changes they requested. If you change the calculatePay method, and inadvertently break the reportHours method; then the COO will start demanding that you never change the calculatePay method again.

He goes on to later re-state the SRP in simpler terms:

Another wording for the Single Responsibility Principle is:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

Wikipedia has a simpler definition:

In object-oriented programming, the single responsibility principle states that every context (class, function, variable, etc.) should have a single responsibility, and that responsibility should be entirely encapsulated by the context. All its services should be narrowly aligned with that responsibility.

Which specifically tells you that you can have a class that causes multiple other changes, based on interaction with the specified class (or button).

It goes on to give the example of a report class:

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

  • 1
    Thanks! It was usefull! After read BlackWasp's articles, I also recommend. It has good examples!
    – korima
    Oct 14, 2014 at 7:01

I agree with Ampt's comment:

If you assume that the buttons responsibility is to take in user input and call the appropriate method, then you aren't violating the SRP.

In your case it would be more important to distinguish between functionality and presentation - to separate the GUI and the code that is run when clicking the button. Event handling is part of the GUI, so it can stay there, but coupling the actual functionality of the button to the GUI I would not recommend.

This should be your SRP focus in this particular case. As it often is with SRP, keeping presentation and code apart can be very helpful. There's a reason architectures such as MVC are so popular.


Your button class does do just one thing: it manages the state of the button. The fact that the button can do multiple things or has multiple behaviors has no bearing on the single responsibility principle.

Where the principle comes to bear is in the implementation -- if the button has two behaviors, each behavior should be through a different method. Don't create one method that handles both through a series of if statements.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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