SRP w C# - co oznacza zasada jednej odpowiedzialności?

Klasa, która jednocześnie waliduje zamówienie, zapisuje je do bazy, generuje fakturę i wysyła wiadomość e-mail, zwykle nie psuje się od razu. Problemy zaczynają się przy kolejnej zmianie, gdy modyfikacja formatu faktury dotyka logiki zapisu albo test wymaga uruchomienia całej infrastruktury. Dlatego pytanie „SRP, co to właściwie znaczy?” najlepiej przełożyć na codzienne decyzje projektowe, a nie na definicję do zapamiętania.

SRP oznacza jedną przyczynę zmiany

SRP to skrót od Single Responsibility Principle, czyli zasady jednej odpowiedzialności. Jest pierwszą literą zbioru zasad SOLID i mówi, że klasa powinna mieć jeden powód do zmiany.

To sformułowanie jest ważniejsze niż popularne, ale zbyt uproszczone hasło „klasa powinna robić jedną rzecz”. Jedna rzecz może składać się z kilku metod. Jeżeli wszystkie służą temu samemu aktorowi biznesowemu i zmieniają się z tego samego powodu, ich wspólna obecność może być całkowicie uzasadniona.

Co oznacza „powód do zmiany”

Wyobraźmy sobie moduł obsługujący raport sprzedażowy. Zmiana reguł wyliczania wyniku wynika z potrzeb działu finansowego, a zmiana formatu pliku PDF z wymagań użytkownika lub systemu raportowego. To są dwa niezależne powody do modyfikacji, więc obie odpowiedzialności nie powinny być ciasno związane w jednej klasie.

W praktyce pytam wtedy, kto może zażądać zmiany w tym kodzie. Jeżeli odpowiedź brzmi „księgowość, administrator bazy i frontend”, prawdopodobnie patrzę na kilka odpowiedzialności sklejonych w jeden komponent.

SRP nie oznacza jednej metody w każdej klasie

Klasa Order może zawierać kilka metod związanych z zachowaniem zamówienia, na przykład dodawanie pozycji, sprawdzanie poprawności i obliczanie sumy. Wszystkie dotyczą tego samego obszaru domeny, więc rozbijanie ich tylko dlatego, że jest ich kilka, byłoby przesadą.

zależy od poziomu abstrakcji. Inaczej oceniamy pojedynczą metodę, inaczej klasę domenową, a jeszcze inaczej moduł aplikacji. SRP jest wskazówką projektową, a nie mechanicznym zakazem posiadania więcej niż jednej operacji.

Jak rozpoznać naruszenie zasady jednej odpowiedzialności

Najłatwiej zauważyć problem po tym, że klasa zaczyna znać zbyt wiele szczegółów. Kontroler ASP.NET Core obsługuje żądanie, wykonuje skomplikowane reguły biznesowe, buduje zapytanie SQL i formatuje odpowiedź. Taki kod może działać, ale każda zmiana wymaga ostrożności w kilku różnych obszarach.

Jednym z najbardziej czytelnych zapachów kodu jest klasa typu InvoiceManager, która jednocześnie liczy kwoty, zapisuje dane, generuje dokument i wysyła go klientowi. Sama nazwa może brzmieć niewinnie, lecz zakres odpowiedzialności jest już bardzo szeroki.

Nie traktuję jednak liczby linii ani liczby metod jako dowodu naruszenia SRP. Klasa może mieć 300 linii i nadal opisywać jeden spójny proces, a inna może mieć 40 linii i łączyć dwa zupełnie różne powody zmian. Najważniejsza jest spójność zmian, nie rozmiar pliku.

Przykład SRP w C# przed i po refaktoryzacji

Spójrzmy na typowy serwis aplikacji .NET. W pierwszej wersji jedna klasa zajmuje się walidacją, zapisem zamówienia, generowaniem faktury i komunikacją z klientem.

public class OrderService
{
    public async Task PlaceAsync(Order order)
    {
        Validate(order);
        await SaveToDatabaseAsync(order);

        var invoice = GenerateInvoice(order);
        await SendEmailAsync(order.CustomerEmail, invoice);
    }

    private void Validate(Order order) { }
    private Task SaveToDatabaseAsync(Order order) => Task.CompletedTask;
    private Invoice GenerateInvoice(Order order) => new();
    private Task SendEmailAsync(string email, Invoice invoice)
        => Task.CompletedTask;
}

Problem nie polega na samej liczbie metod. Każdy z tych fragmentów może zmienić się z innego powodu. Reguły walidacji zmieni biznes, sposób zapisu zmieni zespół odpowiedzialny za dane, format faktury zmieni księgowość, a dostawcę wiadomości może wymienić administrator systemu.

Po refaktoryzacji serwis może koordynować proces, a szczegóły trafią do komponentów o wyraźniejszych granicach.

public sealed class OrderService
{
    private readonly IOrderValidator _validator;
    private readonly IOrderRepository _repository;
    private readonly IInvoiceGenerator _invoiceGenerator;
    private readonly IEmailSender _emailSender;

    public OrderService(
        IOrderValidator validator,
        IOrderRepository repository,
        IInvoiceGenerator invoiceGenerator,
        IEmailSender emailSender)
    {
        _validator = validator;
        _repository = repository;
        _invoiceGenerator = invoiceGenerator;
        _emailSender = emailSender;
    }

    public async Task PlaceAsync(
        Order order,
        CancellationToken cancellationToken)
    {
        _validator.Validate(order);
        await _repository.SaveAsync(order, cancellationToken);

        var invoice = _invoiceGenerator.Generate(order);

        await _emailSender.SendAsync(
            order.CustomerEmail,
            invoice,
            cancellationToken);
    }
}

Nowy OrderService nadal wywołuje kilka komponentów, ale jego odpowiedzialnością jest koordynowanie procesu złożenia zamówienia. Nie musi wiedzieć, czy dane trafiają do SQL Servera, jak powstaje PDF ani z którego dostawcy poczty korzysta aplikacja.

To rozdzielenie przynosi konkretną korzyść. Mogę przetestować generator faktur bez bazy danych, a zmianę sposobu wysyłki wiadomości przeprowadzić bez dotykania reguł zamówienia. Właśnie w takich sytuacjach SRP przestaje być teorią i zaczyna realnie obniżać koszt zmian.

Co SRP daje aplikacji .NET

Największą wartością nie jest samo posiadanie większej liczby klas. Zyskujemy wtedy, gdy kod można zmieniać lokalnie, bez niepotrzebnego uruchamiania lawiny zależności.

Łatwiejsze testowanie

Klasa, która zajmuje się jedną odpowiedzialnością, zwykle potrzebuje mniejszej liczby zależności. Test walidatora nie musi tworzyć połączenia z bazą ani przygotowywać atrap systemu e-mail. Dzięki temu testy są szybsze, czytelniejsze i lepiej pokazują, co właściwie sprawdzają.

Mniejsze ryzyko regresji

Gdy format odpowiedzi API jest oddzielony od logiki domenowej, zmiana kontraktu HTTP nie powinna przypadkowo zmienić sposobu naliczania ceny. Odseparowanie powodów zmian ogranicza liczbę miejsc, które trzeba analizować przed wdrożeniem.

Przeczytaj również: var w JavaScripcie - zakres, hoisting i pułapki starego kodu

Prostsza praca zespołowa

Podział odpowiedzialności ułatwia równoległą pracę. Jedna osoba może zmieniać repozytorium, druga reguły domenowe, a trzecia integrację z Azure Service Bus. Konflikty w kodzie nadal są możliwe, ale dobrze wyznaczone granice zmniejszają ich prawdopodobieństwo.

Warto też pamiętać o zależnościach. Samo wydzielenie klasy nie wystarczy, jeżeli nowy komponent nadal zna szczegóły wszystkich pozostałych warstw. SRP działa najlepiej razem z kontrolą zależności, interfejsami tam, gdzie są potrzebne, oraz sensownym podziałem na domenę, aplikację i infrastrukturę.

Kiedy nie dzielić klasy na siłę

Najczęstszy błąd polega na zamianie SRP w konkurs na najmniejsze klasy. Jeżeli każda linia trafia do osobnego serwisu, kod zyskuje więcej abstrakcji, ale traci czytelność. Zamiast jednego prostego modelu pojawia się kilkanaście interfejsów, fabryk i klas pośrednich.

Mała aplikacja, prototyp albo prosty endpoint nie zawsze potrzebuje rozbudowanej architektury. Jeżeli klasa ma jedną spójną odpowiedzialność, łatwo ją testować, a zmiany nie rozlewają się na inne obszary, dalsze dzielenie może być zwykłym overengineeringiem, czyli komplikowaniem rozwiązania ponad realną potrzebę.

Przed refaktoryzacją zadaję sobie trzy pytania:

• Czy różne fragmenty klasy zmieniają się z różnych powodów?
• Czy za te zmiany odpowiadają różne osoby, zespoły albo obszary biznesowe?
• Czy wydzielenie nowej klasy poprawi testowanie lub czytelność, a nie tylko zmniejszy liczbę linii?

Jeśli odpowiedzi są przeczące, zostawienie kodu w jednej klasie może być rozsądniejsze. Dobra granica jest ważniejsza niż formalna liczba komponentów. Zasada ma pomagać w zarządzaniu zmianą, a nie wymuszać sztuczny podział.

Najlepszy test SRP robi się przed kolejną zmianą

Gdy nie wiem, czy klasa łamie zasadę jednej odpowiedzialności, wyobrażam sobie trzy niezależne wymagania. Zmianę reguł biznesowych, zmianę sposobu przechowywania danych i zmianę formatu prezentacji. Jeżeli za każdym razem muszę modyfikować ten sam komponent, granica prawdopodobnie została wyznaczona zbyt szeroko.

W skrócie, SRP nie mówi, że każda klasa ma robić tylko jedną małą czynność. Mówi, że kod powinien skupiać rzeczy, które zmieniają się z tego samego powodu, i rozdzielać te, które podlegają różnym decyzjom. To prosta zasada, ale stosowana z wyczuciem potrafi wyraźnie poprawić jakość aplikacji .NET.