Przedstawiony kod łamie jedną z fundamentalnych zasad SOLID. Którą?

Poprawna odpowiedź: C

Uzasadnienie i szersze wyjaśnienie:

Zasada jednej odpowiedzialności (Single Responsibility Principle - SRP), pierwsza z zasad SOLID, mówi, że każda klasa (lub moduł) powinna mieć tylko jeden powód do zmiany. Innymi słowy, powinna być odpowiedzialna tylko za jeden, spójny aspekt funkcjonalności systemu.

Przeanalizujmy przedstawioną klasę ReportManager:

• Posiada ona metodę GenerateReport, która jest odpowiedzialna za tworzenie (generowanie) treści raportu. Jest to jedna odpowiedzialność.
• Posiada również metodę SaveReportToFile, która jest odpowiedzialna za zapisywanie raportu do systemu plików. Jest to zupełnie inna odpowiedzialność, związana z operacjami wejścia/wyjścia.

Klasa ReportManager ma więc dwa powody do zmiany:

1. Zmiana logiki generowania raportu (np. zmiana formatu, dodanie nowych danych).
2. Zmiana sposobu zapisu (np. zapis do bazy danych zamiast pliku, dodanie kompresji).

Posiadanie dwóch różnych odpowiedzialności w jednej klasie jest bezpośrednim złamaniem zasady jednej odpowiedzialności. Poprawna refaktoryzacja polegałaby na rozbiciu tej klasy na dwie mniejsze, np. ReportGenerator i ReportSaver.

Dlaczego pozostałe odpowiedzi są nieprawidłowe?

• A. Zasada otwarte-zamknięte: Mówi, że byty programistyczne powinny być otwarte na rozszerzenia, ale zamknięte na modyfikacje. Problem w kodzie nie dotyczy rozszerzalności, a mieszania odpowiedzialności.
• B. Zasada podstawienia Liskov: Dotyczy poprawnego działania polimorfizmu w hierarchii dziedziczenia. W tym przykładzie nie ma żadnej hierarchii klas.
• D. Zasada odwrócenia zależności: Mówi, że moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu, a obie powinny zależeć od abstrakcji. W tym prostym przykładzie nie widać problemów z zarządzaniem zależnościami, a problem ze spójnością samej klasy.