Tworzenie kodu według najlepszych praktyk
2 godz. 45 min · Full-stack i Programowanie
Rafał PiekaraSoftware KomandosNie zrozumiesz SOLIDa bez teoretycznych podstaw. Przejdziemy przez założenia stojące za każdą z nich. Przeanalizujemy problemy, które możesz spotkać oraz dowiesz się dlaczego ciągle jeszcze tak wielu programistów nie stosuje się do tych zasad.
Ruby i Typescript to technologie, które świetnie odzwierciedlają uniwersalizm SOLIDa. Te złote zasady działają w językach dynamicznie typowanych i interpretowanych jak Ruby oraz przy statycznym typowaniu na przykładzie Typescript.
Zanim zabierzesz się za programowanie warto poćwiczyć SOLIDny sposób myślenia. Zmierzysz się z zadaniami, w ramach których będziesz projektować kod tak, aby wszystkie zasady SOLID znalazły w nim swoje zastosowanie.
Prawda jest taka, że kod, z którym w większości pracujemy ma swoją historię. Czasami historia ta jest tak bolesna, że klasy i metody są zagmatwane, poplątane i trudne w utrzymaniu. Gdy dotrzesz do tego miejsca będziesz mieć w arsenale wszystkie potrzebne narzędzia, żeby zmierzyć się z zadaniami praktycznymi, które przekształcą kod legacy w SOLIDne arcydzieło.
Tak ważny temat, jak testowanie nie może zostać pominięty. Między innymi po to też stosujemy zasady SOLID, żeby nasz kod praktycznie sam się testował. Napiszesz więc testy, których wzorce możesz wykorzystać w dowolnym projekcie, dowolnej technologii, jeśli tylko kod, który testujesz będzie spełniał wymagania zasad SOLID.
Nie ma znaczenia, czy dopiero zaczynasz przygodę z programowaniem, czy też jesteś starym wyjadaczem, który klasami i interfejsami myśli przy zagryzaniu tosta na śniadanie. Ten kurs jest właśnie dla Ciebie. Technologia ani język programowania też nie mają znaczenia. Zasady SOLID to uniwersalny zbiór. Ich znajomość sprawi, że Twój kod będzie lepszy, łatwiejszy w utrzymaniu i odporny na perturbacje i zmiany.
A oto przykład, z którym zmierzymy się refaktoryzacji kod Zgodnie z zasadą LSB
widzisz, że mamy dwie klasy admin account i User Account i admin Account ma zmianę
logiki w stosunku do User account.
Mianowicie mam metodę Access resource, która rzuca nam wyjątkiem jeśli
admin nie ma odpowiednich uprawnień.
W tym momencie te dwie klasy nie mogą być zamiennie przedstawiane, ponieważ
implementują ten sam interfejs, ale ten sam interfejs
sprawia, że nadpisanie metody Access Resource
w klasie admin zmienia jej zachowanie i musimy doprowadzić to do porządku.
W pierwszej kolejności spróbujmy dodać metodę sprawdzania uprawnień
także w klasie użytkownika.
Więc dodajmy sobie jakiś permission i zwracamy false, bo nasz user nie będzie
miał żadnych uprawnień, bo tylko admin.
A więc tutaj zmienimy w adminie nazwę metody permission na permission.
Tak aby ten interfejs był spójny.
I w tym momencie uzyskaliśmy wspólne interfejsy dla obu klas.
Mamy access resource, mamy Permission access resource permission.
Jest ok. Tutaj zmienimy.
Tylko nazwę na odpowiedni warunek.
I żeby te interfejsy były takie same, żebyśmy mogli oczekiwać pewnych podobnych
zachowań po użytkowniku i po adminie.
Dodajmy tutaj wywołanie i rzucenie wyjątku jeśli użytkownik nie ma odpowiednich
uprawnień, bo te uprawnienia może w trakcie działania programu
mogą się jakoś zmienić.
W tym momencie i tak szybko z refaktoryzacji ten kod żeby
umożliwiał podstawienia zgodnie z zasadą LSB, bo obie klasy mają to samo zachowanie
przy wywołaniu metody Access resource może ona rzucić wyjątkiem lub
zwrócić jakąś wartość.
Jak będziemy to testować pokażę Ci w kolejnym materiale.