1

The SOLID principle is supposed to be the underlying framework for object oriented programming. The "S" part stands for: "Single responsibility principle" which in wikipedia is defined as:

A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class

I understand this conceptually, however in this repo an example is given of the single responsibility principle where a class, since is should only have one job, should be limited to one method (besides the __init__). The developer of this small repo seems to advocate a one-method per class principle, which would ensure single responsibility. A new method should be part of a new class, and then the facade pattern can be used to basically instantiate the lower-level class within the higher level class.

In practice however, there are tons of examples in python where classes have many responsibilities. Take, for instance a simple composite pattern:

class ChildElement:
        def __init__(self, name):
                self.name = args[0]
        def printDetails(self):
                print("\t", end = "")
                print(self.name)

class CompositeElement:
        def __init__(self, name):
                self.name = name
                self.children = []
        def appendChild(self, child):
                self.children.append(child)
        def removeChild(self, child):
                self.children.remove(child)
        def printDetails(self):
                print(self.name)
                for child in self.children:
                        print("\t", end = "")
                        child.printDetails()

The class CompositeElement seems to contain several methods, one to append a child, one to remove a child and one to print the details of the composite. This seems to violate the single responsibility principle as outlined by the example in the repo above.

What does single responsibility truly imply in the context of an object oriented python program? Is it really having one method per class? If so why do so many GoF design patterns not abide by this rule?

Thanks

  • There are many things wrong with that attitude. For one, that single method might very well perform totally unrelated duties and so violate SOLID anyway. In fact, restricting your classes to only one method would encourage doing exactly this. – Kilian Foth Nov 28 '19 at 9:39
  • 1
    See my explanation about the meaning of SRP in a context of a class (specifically the second part about multiple public methods). – Arseni Mourzenko Nov 28 '19 at 10:04
2

Thinking "SRP means that a class/module should have only one reason to change" might be ambiguous. What SRP really means is that each class/module should have responsibility for a single part of your software (which at the end also achieves separation of concerns).

Here the responsibility of the composite class is the storage of child class. this is why it needs an append and remove method. However, for me, the printDetails method should not be in this class : its role is to store and not to print. For example it should have a method getChilds used by an other class which will then print the data as needed.

Having only one function per class/module would be wrong because a in order to handle a single part of a software, we need to do different things and a function is meant to do only one thing.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.