# Advancing Single Responsibility Principle

The Single-Responsibility Principle is one of the five basic Agile design principles formulated by R.C. Martin^{[1]}. The principle defined as follows:

A class should have only one reason to change.

In the definition "a reason to change" equals to "a responsibility". Paraphrased, this principle is "a class should have only one responsibility". In broaden terms, "a responsibility" is a condition of being responsible, e.g. having ownership of the entire task and its outcome or having full control over the process. A class is not the largest or smallest structured element of the program. For different software development paradigm it can be either module or function.

That brings several other definitions:

- A class should control only one process.
- A component should have ownership over only one task.
- A function should be accounted only for one result.

In these definitions the left part is a structural element of the computer program. The right element is an element of the problem domain. "Should have only one" means that one element of computer program is associated with the exactly one element of problem domain. If we call the set of the elements of the program "a domain, X" and the set of the associated elements of the problem domain as "a codomain, Y", what we get is a function that associate one element of the domain (computer program) with element of the codomain (problem domain).

$ f: \mathbb X \to \mathbb Y $

It is important, that the inverse function from the problem domain to the elements of the computer program does not exist, because the single element of the problem domain can be associated with many elements of the program.

The sets X and Y are finite sets and small enough to define this function as the mapping table between classes, their instances, interfaces, methods, functions, properties, etc (element of the program) and roles, actors, instructions, processes and their characteristics (elements of the problem domain).

Robert C. Martin.

*Agile software development: principles, patterns, and practices.*Prentice Hall, 2002. ↩︎