What is your best example of a violation of the Single Responsibility Principle?

Question

I'm looking for some good examples of code that violates the Single Responsibility Principle. Don't show me any examples from Uncle Bob's books or web sites since those are plastered all over the internet, like this one:

interface Modem
{
    public void dial(String pno);
    public void hangup();
    public void send(char c);
    public char recv();
}

Answer 1

The clue about SRP is to define the responsibilities so that your implementation does just that thing. It's like you're making a rule (by giving a class a name and a responsibility) and then trying to follow it.

So if you're not following it you're either not defining the rule properly or you're being inconsistent while implementing it (or both, which might actually be the most common case).

I generally find the classes that do not give a half-decent try at defining a single main responsibility or good name to be the best violations. Then you'll just have to read the whole class to try to determine if there's any well defined responsibilities at all.

Answer 2

Here's some code from a PHP project I had to take on:

class Session
{
    function startSession()
    {
        // send HTTP session cookies
    }

    function activateUserAccount()
    {
        // query the DB and toggle some flag in a column
    }

    function generateRandomId()
    {}

    function editAccount()
    {
        // issue some SQL UPDATE query to update an user account
    }

    function login()
    {
        // perform authentication logic
    }

    function checkAccessRights()
    {
        // read cookies, perform authorization
    }
}

I believe this class does waaay to much.

Answer 3

The granularity of your OO design is a matter of taste and might be inapropriate for others. Thus, I wouldn't look for examples of breaking the single responsibility principle in some business-logic-class, discussing whether it has too much or too little to do.

In my opinion, the best examples (with worst side-effects) come from breaking the layering of your application. F.ex.:

• Performing business logic in the data access layer (whose only responsibility should be providing persistence access to the application)
• Accessing business services from (through) the domain model (whose only responsibility should be to store most of the application's state)
• Performing complex business logic in the view layer (responsible for data presentation & user input)

Answer 4

Actually, in most OO languages that I have used, the top-level Object class is a good example. In Ruby, for example, the Object class (or more precisely the Kernel mixin, which gets mixed into Object) has 45 public instance methods. Now, some of those are aliases, but there's still got to be at least 20, and they are from all over the place. I can easily identify at least 5 responsibilities.

Now, I don't mean to pick on Ruby. It is my favorite programming language. That's why I used it as an example: because it's the language I'm most familiar with. And I am reasonably sure that what I wrote about Ruby applies 100% also to at least Java and .NET.