SOLID Class Design: The Single Responsibility Principle

This is part one of a five part series about SOLID class design principles by Robert C. Martin. The SOLID principles focus on achieving code that is maintainable, robust, and reusable. In this post, I will discuss the Single Responsibility Principle.

The Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.

The SRP is roughly the same as having “high cohesion”. A class is said to have high cohesion if it’s behaviours are highly related, and strongly focused. The SRP states that a class should be cohesive to the point that it has a single responsibility, where a responsibility is defined as “a reason for change.”

The Benefits

• The class is easier to understand
  When the class only does “one thing”, its interface usually has a small number of methods that are fairly self explanatory. It should also have a small number of member variables (less than seven-ish).

• The class is easier to maintain
  Changes are isolated, reducing the chance of breaking other unrelated areas of the software. As programming errors are inversely proportional to complexity, being easier to understand makes the code less prone to bugs.

• The class is more reusable
  If a class has multiple responsibilities, and only one of those is needed in another area of the software, then the other unnecessary responsibilities hinder reusability. Having a single responsibility means the class should be reusable without modification.

An Example

Consider a class called XMLExporter. XMLExporter takes a Document object, and exports it into a different file format for another application. Ignoring error handling, the class may look something like this:

class XMLExporter {
private:
    URL _runSaveDialog();
    String _exportDocumentToXML(Document doc);
    void _showSuccessDialog();
public:
    void exportDocument(Document doc);
};

void XMLExporter::exportDocument(Document doc)
{
    String xmlFileContent = _exportDocumentToXML(doc);
    URL fileURL = _runSaveDialog();
    xmlFileContent.writeToURL(fileURL);
    _showSuccessDialog();
}

// ... (code ommitted)

There are at least two reasons for change (a.k.a. responsibilities) in the XMLExporter class. The class needs to be modified if the GUI changes — for example, if an options dialog is added. Also, the class needs to be modified if the XML format changes, or the Document needs to be exported differently.

To apply the SRP to the XMLExporter class, it must be split into two classes. One class will handle the GUI, and the other will only handle the conversion to XML. Here is a possible application of the SRP:

/********* XMLConverter ************/
class XMLConverter {
public:
    String convertDocumentToXML(Document doc);
}

// ... (code ommitted)

/********* XMLExporter ************/
class XMLExporter {
private:
    URL _runSaveDialog();
    void _showSuccessDialog();
public:
    void exportDocument(Document doc);
};

void XMLExporter::exportDocument(Document doc)
{
    XMLConverter converter;
    String xmlFileContent = converter.convertDocumentToXML(doc);
    URL fileURL = _runSaveDialog();
    xmlFileContent.writeToURL(fileURL);
    _showSuccessDialog();
}

// ... (code ommitted)

N.B. The above code demonstrates the SRP only, and actually violates some of the other four SOLID class design principles.

By extracting the XMLConverter class from XMLExporter, the two reasons for change are separated from each other. Note that separating the GUI from the converter has resulted in a model-view-controller type of structure.