Monthly Archives: April 2015

Break Single Responsibility Principle

Single Responsibility Principle (SRP) is not absolute. It exists to help the code maintainability and readability. But from time to time you may see solutions, patterns that break the SRP and are kind of OK. This is also true for other principles, but this time I would like to talk about SRP.

Singleton breaks SRP

The oldest and simplest pattern that breaks SRP is the singleton pattern. This pattern restricts the creation of an object so that there is a single instance of a certain class. Many thinks that singleton actually is an antipattern and I also tend to believe that this is better to use some container to manage the lifecycle of the objects than hard coding singletons or other home made factories. The anti pattern-ness of singleton generally comes from the fact that it breaks the SRP. A singleton has two responsibilities:

  1. Manage the creation of the instance of the class
  2. Do something that is the original responsibility of the class

You can easily create a singleton that does not violate SRP keeping the first responsibility and drop the second one

public class Singleton {
    private static final Singleton instance = new Singleton();
    public static Singleton getInstance() { return instance; }
    private Singleton() {}

but there is not much use of such a beast. Singletons are simple and discussed more than enough in blogs. Let me look at something more complex that breaks SRP.

Mockito breaks SRP

Mockito is a mocking framework, which we usually use in unit tests. I assume that you are familiar with mocking and mockito. A typical test looks like the following:

import static org.mockito.Mockito.*;
List mockedList = mock(List.class);

(sample is taken from the Mockito page, actually mixing two examples). The mock object is created using the static call

List mockedList = mock(List.class);

and after it is used for three different things:

  1. Setup the mock object for its mocking task.
  2. Behave as a mock mocking the real life object during testing.
  3. Help verification of the mock usage.

The call


sets up the mock object. The calls


use the core responsibility of the mock object and finally the lines


act as verification.

These are three different tasks not one. I get the point that they are closely related to each other. You can even say that they are just three aspects of a single responsibility. One could argue that verification only uses the mock object as a parameter and it is not the functionality of the mock object. The fact is that the mock object keeps track of its mock usage and acts actively in the verification process behind the scenes. Okay, okay: these all may be true, more or less. The real question is: does it matter?

So what?

Does the readability of the code of Mockito suffer from treating the SRP this way? Does the usability of the API of Mockito suffer from this?

The answer is definite NO for both of the questions. The code is as readable as it gets (imho it is more readable than many other open source projects) but it is not affected by the fact that the mock objects have multiple responsibilities. As for the API you can even say more. It is readable and usable even more with this approach. Former mocking frameworks used strings to specify the method calls like


(fragment from the page), which is less readable and error prone. A typo in the name of the method is discovered test run time instead of compile time.

What is the morale? Don’t be dogmatic. Care programming principles, since they are there to help you to write good code. I do not urge anyone to ignore them every day. On the other hand if you feel that some of the principles restrict you and your code would be better without it, do not hesitate to consider writing a code that breaks the principles. Discuss it with your peers (programming is a team work anyway) and come to a conclusion. The conclusion will be that you were wrong considering to break SRP in 90% of the cases. In 10%, however, you may come up with brilliant ideas.


Sometimes you need tuples in Java. Or not.

Tuple is an ordered list of elements. In Java that is List<Object>. Even though it exists there is an extra need from programmers for tuples. You can see that there is a package named javatuples that defines tuples that contain 1, 2 up to 10 elements. (Btw: There is a class in the package named Unit that contains one element. WAT?) There is a long discussion on stackoverflow about tuples.

But where does it come from? Why do some Java programmers long for tuples? The answer is that tuples are part of the language constructs of other languages. They date back to such old ages that only program archeologist can remember. Languages like LISP use tuples. Python is also lurking here from the last century. Why did they implement a feature like tuples? Perhaps it seemed to be a good idea. If it was not coming from the past, Java developer would not long for it. Which itself is a hint: do you really need it? But the fact is fact:

Java misses tuples. THIS IS A LIE!

Which is not true for two reasons:

  1. There is no need for tuples.
  2. There is a built in type in Java that can handle tuple

There is an interface named java.util.Map.Entry that is there just to hold two objects and there is a simple implementation java.util.AbstractMap.SimpleEntry. Thus Java does not misses tuples and neither do I.