Single Responsibility Principle

Kig fx på følgende klasser

public abstract class Statistics
{
    public abstract void CollectData();
    public abstract double CalculateMean();
}

public class ValueStatistics : Statistics
{
    private readonly IList values = new List();

    public override void CollectData()
    {
        var done = false;
        values.Clear();
        do
        {
            Console.Write("Enter value (int): ");
            var line = Console.ReadLine();
            try
            {
                var number = Convert.ToInt32(line);
                values.Add(number);
            }
            catch (FormatException)
            {
                done = true;
            }
        } while (!done);
    }

    public override double CalculateMean()
    {
        return values.Average();
    }
}

Klassen Statistics slår her bro over to ansvarsområder: Et som har med indsamling af data at gøre og et andet som har med databehandling at gøre. De to ansvarsområder ser oveni købet umiddelbart ud til at være ortogonale, sådan at forstå at de kan variere uafhængigt uden at ændringer for det ene område påvirker det andet.

For den abstrakte Statistics er det ligegyldigt hvordan data er indsamlet når blot det giver mening efterfølgende at tale om beregningen af en middelværdi. Og præcis så langt som vi har tænkt nu giver det fuldt ud mening for en ValueStatistics. Vi kunne endda indføre nye nedarvede klasser, som deler de samme traits som ValueStatistics, fx en WordLengthStatistics, ToneCalibratorStatistics eller … find selv på flere.

Introduktion af ny feature vælter læs

Vi forbryder os mod Single-Responsibility-Princippet [1]:

Enhver klasse bør kun have en grund til at ændres

Pludselig opstår der spørgsmål som komplicerer vores hidtidige implementation af statistikker, som udelukkende skyldtes en forsimplende antagelse om at indsamling af data kan foregå uafhængigt af middelværdi-beregningen, som angivet i Statistics, hvor de to begreber kobles sammen på en uhensigtsmæssig måde.

Mulig løsning ved at opdele funktionaliteter

Ved fx at splitte statistik klassen op i interfaces svarende til hver af dens hovedområder, lettes implementationen af de nye krav, idet kun MonetaryAmountStatistics klassen påvirkes heraf. De to begreber, indsamling og beregninger kan nu variere uafhængigt af hinanden.

public interface ICollectable
{
    void CollectData();
}

public interface IMeanSpreadable
{
    double CalculateMean();
}

public class ValueStatistics : ICollectable, IMeanSpreadable
{
    ...
    public void CollectData() { ... }
    public double CalculateMean() { ... }
}

public class Amount  {  ...  }

public interface IMultipleMeansSpreadable
{
    T[] CalculateMeans();
}

public class MonetaryAmountStatistics : ICollectable, IMultipleMeansSpreadable
{
    public void CollectData() { ... }
    public Amount[] CalculateMeans() { ... }
}

Ovenstående kan også siges at være en anvendelse af ISP-princippet, mere om dette i en senere artikel. Se de andre artikler herunder.

Referencer

[1] “Agile, Principles, Patterns and Practices in C#”, Martin/Martin, s. 115-

[2] http://en.wikipedia.org/wiki/Single_responsibility_principle