Zasady S.O.L.I.D – Single Responsibility Principal

W Inżynierii oprogramowania SOLID oznacza zestaw podstawowych zasad projektowania oprogramowania. Każda literka w wyrazie jest skrótem do jakieś zasady. ‘S’ oznacza Single Responsibility Principal. Podejrzewam, że większość osób doskonale zna już tą zasadę. Aby jednak zachować pewien porządek na blogu będę tłumaczył nawet te oczywiste reguły:).

W skrócie zasada mówi, że każdy obiekt (klasa) powinien być odpowiedzialny za jak najmniejszy fragment logiki. Niedopuszczalne jest aby klasa wykonywała dwie niezależne od siebie funkcje. Robert Martin (autor SRP) definiuje odpowiedzialność jako “reason to change”. Innymi słowy, każda klasa powinna mieć wyłącznie jeden powód do zmiany. Jeśli brzmi to zbyt abstrakcyjnie to rozważmy akademicki przykład klasy wykonującej jakieś obliczenia (choćby mnożenie macierzy – obojętnie). Jeśli taka klasa oprócz wykonywania obliczeń odpowiedzialna jest również za wyświetlenie wyników z pewnością nie spełnia zasady SRP.

Ostatnie pytanie brzmi: jak weryfikować zgodność kodu z SRP? Przede wszystkim należy to do obowiązków programisty. Żadne narzędzia w pełni nie zagwarantują poprawności. Nie mniej jednak, można wspomóc się kilkoma metrykami kodu. Za pomocą narzędzia nDepend można wyliczyć metrykę efferent coupling, która określa jak wiele zewnętrznych klas wywołuje badany fragment kodu. Gdy CE jest zbyt wysokie istnieje prawdopodobieństwo, że klasa nie spełnia SRP. Przydatne również są wszystkie metryki mierzące liczbę powiązań (np. ABC).

Na koniec należy dodać, że nie wszystkie klasy w programie muszą spełniać SRP. Warstwa usług czy wszelkie implementacje wzorca fasady z definicji przecież nie są zgodne z SRP – mają za zadanie skupiać szeroką funkcjonalność w jednym miejscu.

One thought on “Zasady S.O.L.I.D – Single Responsibility Principal”

Leave a Reply

Your email address will not be published.