SOLID - Single responsible principle

Pierwsza zasada mnemoniku SOLID. Zgodnie z tą praktyką klasa powinna mieć tylko jedną odpowiedzialność. Musi istnieć jeden powód do jej zmiany. Dzięki temu łatwiej jest nam zrozumieć cel danej klasy, czyli jakie jest jej główne zadanie. Właśnie takie słowa wypowiedział znany nam wszystkim Uncle Bob:

A class should have only one reason to change.

Robert C. Martin

“Człowiek orkiestra” nie powinien znaleźć swojego odzwierciedlenia w kodzie

Przechodząc do przykładu:

1
2
3
4
5
6
7
8
9
10
public class Boss {
    
  public void scheduleMeeting(Date date) {
    // schedule a meeting for specified date
  }

  public void figureOutMarketingPlan() {
    // create a marketing plan 
  }
}

Klasa Boss na pewno ma za dużo zadań (powodów do zmiany). Gdyby przyszło wymaganie zmieniające sposób ustalania spotkań (np. z zapisywania w notesie na wpisywanie ich do komputera) albo sposób tworzenia planu marketingowego (np. z kreatywnego na sprawdzone rozwiązania) to nasza encja musiałaby zostać zmieniona. Dlatego zgodnie z zasadą Pojedynczej Odpowiedzialności, należy rozbić te zadania na dwie oddzielne klasy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class Secretary {

  public void scheduleMeeting(Date date) {
    // schedule a meeting for specified date
  }
}

public class MarketingSpecialist {

  public void figureOutMarketingPlan() {
    // create a marketing plan 
  }
}

public class Boss {
    
  private Secretary secretary;
  private MarketingSpecialist marketingSpecialist;

  public Boss(Secretary secretary, MarketingSpecialist marketingSpecialist) {
    this.secretary = secretary;
    this.marketingSpecialist = marketingSpecialist;
  }

  public void scheduleMeeting(Date date) {
    secretary.scheduleMeeting(date);
  }

  public void figureOutMarketingPlan() {
    marketingSpecialist.figureOutMarketingPlan();
  }
}

Teraz nasz Boss może oddelegować zadania do osób, które są ekspertami w tych dziedzinach. Jest to jego jedyne zadanie, jak na szefa przystało! Secretary i MarketingSpecialist mają po jednej odpowiedzialności, więc wszystko jest zgodne z zasadą SRP. Nasz szef nawet nie musi znać sposobu w jaki jego pracownicy wykonają swoje zadania 😎.

Podsumowanie

Należy mieć na uwadze, że ta zasada jest tylko wskazówką. Nie należy trzymać się jej w stu procentach ani też traktować poważnie. Zawsze należy zachować umiar i zdrowy rozsądek. Trzeba zawsze patrzeć przez pryzmat aktualnie rozwijanego projektu. Czy spełnienie zasady Single Resposible Principle dla danego fragmentu oprogramowania jest naprawdę konieczne i opłacalne. Czy nie tracimy pieniędzy na coś co nie jest naszym kluczowym biznesem. Może lepiej jest zostawić kod w aktualnym stanie i skupić się na rdzeniu aplikacji, gdzie podążanie za zasadami ułatwi nam jego częste modyfikowanie.

Chciałbym Cię nakierować na to, żebyś wypracował jak najlepsze rozwiązanie dla siebie. Może kompletny brak fundamentalnych zasad będzie najlepszy dla Twojego biznesu albo wręcz ślepe podążanie za nimi. Wypracuj swój własny styl i bądź otwarty na dyskusje!

Daj znać w komentarzu lub napisz do mnie czy Twoja interpretacją tej reguły jest zbieżna z moją. Może inaczej postrzegasz tą zasadę albo masz inny przykład, który tłumaczy SRP w bardziej przystępny sposób. Zapraszam Cię serdecznie do dyskusji.