0

I've a VolumeButton which derives from ButtonModifier. If I put my business logic (volume up/down, mute, etc) into VolumeButton, enable/disable logic to base class ButtonModifier. Like,

public class VolumeButton : ButtonModifier
{
    /// Event handler to change the volume.
    void ChangeVolume() { ... }
}

public class ButtonModifier
{
    /// Updates the visibility of the button.
    void UpdateVolumeVisibleStatus() { ... }

    /// Enable or disable the button.
    void Enable(bool enable) { ... }
}

On one hand, only business logic change affects VolumeButton, and infrastructure change affects ButtonModifier. So it conforms to SRP. On the other hand, VolumeButton inherited the enable/disable logic from base class. So it has two responsibilities?

Does these two class conform to SRP?

Yang Nan
  • 1
  • 2

2 Answers2

0

Both VolumeButton and ButtonModifier has only one reason to change separately. So they literally conform to the SRP. However, intuitively I think VolumeButton inherits the responsibilities from ButtonModifie, which cause it to violate the SRP.

From the perspective of code dependencies, you did not decouple any dependency by moving one responsibility from the derived class to the base class. According to Uncle Bob's "Agile Principles, Patterns and Practices in C#" Chapter 8, in all the examples, Uncle Bob introduced extra abstractions to separate the responsibilities. So a helpful hint to your question could be "Have you introduced extra abstraction to decouple the dependencies?"

Irwin
  • 101
  • 1
0

I don't think they are conform to SRP, because derived class gets all the public/protected members from its base class, for instance:

public class Flyable
{
    public void fly(){...}
}
public class Bird : Flyable
{
    public void walk(){...}
}

the Bird can fly and walk. Maybe the example is not exactly for your case. But what I'm want to say is that the derived class will get two responsibilities if the two responsibilities are separated with one in base and another in derived.