mardi 23 mars 2021

Does the decorator pattern violate SOLID principles?

Let's say we have a component class like this:

class Component:
    def operation(self) -> str:
        return f"Performing operation"

    def another_operation(self) -> str:
        return f"Performing another operation"

We then have a child of component that overrides both of its methods:

class ChildComponent(Component):
    def operation(self) -> str:
        return f"Performing operation differently"

    def another_operation(self) -> str:
        return f"Performing another operation differently"

We may then define a decorator that modifies the behaviour of operation:

class Decorator(Component):
    _component: Component = None

    def __init__(self, component: Component) -> None:
        self._component = component

    def operation(self) -> str:
        return f"Decorated...({self._component.operation()})"

    def another_operation(self) -> str:
        return self._component.another_operation()

From my understanding, even though we are not modifying the behaviour of another_operation() in the decorator, we must still define it rather than rely on the superclass method otherwise Component's another_operation() will be called instead of ChildComponent's method, and you'd have a bad hybrid situation on your hands.

If we were to do that however, then any time the Component class gained a new method, we'd have to add it to the decorator too, which isn't in keeping with the Interface Segregation Principle. So we either have to violate SOLID principles and maintain twice the amount of code that we need to, or risk using the wrong methods for those we don't explicitly override in the decorator.

Could someone please provide some clarity around this?

Aucun commentaire:

Enregistrer un commentaire