Single-responsibility Principle

This principle states that: A class should have one and only one reason to change, meaning that a class should have only one job.

A classic example is the one with the shapes. Let’s see it:

public class Square{

  private double length;

  public Square(double length) {
    this.length= length;

  public double getLength() {
    return length;
  public void setLength(double length) {
    this.length= length;

  public String getArea() {
     return Double.toString(length * length);

In the code above we have a problem with the getArea() method. The problem is that it handles the logic to output the data, therefore, if the user whats to sort shapes by area or output the data in other format he’s out of luck. This is what SRP frowns against; the shape class should only calculate the area, it should not care how data is formatted.

So, to fix this we can create a Formatter class and use this to handle whatever logic we need to format the area value. The Formatter class would work like this:


Circle circle = new Circle(5);
Formatter formatter = new Formatter();

String area = formatter.formatValue(circle.getArea());


Now, whatever logic we need to output the data to the user is handled by the Formatter class. Also, we have access to the “raw” area value in case we want to use it in computations such as sort by area. Another advantage is that if we need to format the area differently for each user, we can simply use different formatter instances. If we need to support another formatting logic, we don’t need to change our code. We simply build a new formatter class.

3 thoughts on “Single-responsibility Principle

  1. Nice one ! 🙂
    However, in order for the code to be more “readable” I would have used a more suggestive name for the Formatter class, like AreaFormatter or even ShapesAreaFormatter.

    What if your task would have been to implement an Area calculator app that would have received a different shape as parameter and it would return the calculated Area ? Would your Shape objects still implement the getArea() method ?

  2. Thanks. Indeed, I agree that AreaFormatter would be more appropriate in this particular example.

    Regarding the getArea() method, the actual area formula for a shape is constant. We can say it is a computed property of the shape. The calculus logic can’t be changed based on user settings etc.., we can’t have different strategies to compute the area so the answer is yes, each shape should implement its own area property. That said if the property may be computed using multiple formulas/strategies, then I would implement it it in separate class, using the Strategy pattern.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s