Wzorzec DRY

W wielu miejscach powielanie ciągle jednego schematu jest niepotrzebne. Czy to randki z dziewczynami czy spotkania ze znajomymi. Ludzie zaczynają się nudzić przez co przestajemy się bawić tak dobrze, jakbyśmy tego chcieli. Może taki tok rozumowania nie ma bezpośredniego przełożenia na programowanie obiektowe, są jednak inne, podobne powody dla których nie powinniśmy tego robić. Zapraszam do lektury.

Don’t repeat yourself

„Nie powtarzaj sam siebie”, wyjątkowo prosta do zrozumienia zasada, której nazwa mówi sama za siebie. Nie chodzi tu jednak o zwyczajne powielanie kodu, większe znaczenie ma to w przypadku pracy w grupie (chodzi oczywiście o czytelność) lub w przypadku wystąpienia jakiś błędów. Jak zawsze postaram się to ładnie zobrazować konkretnymi przykładami.

DRY w praktyce

Wyobraźmy sobie sytuację, gdzie mamy prostą bazę danych użytkowników. Błędne zastosowanie wzorca DRY

Jak widać obiekt typu użytkownik przechowuje w sobie takie dane jak imię, nazwisko oraz wiek. Dochodzą nam natomiast jeszcze dwie inne zmienne, które przechowują numer ID oraz losową wartość. Dodatkowo id definiujemy dwa sposoby jakimi można dodać osoby do naszej bazy. Albo poprzez obiekt typu User albo poprzez podanie podstawowych parametrów.

Okazuje się jednak, że coś jest nie tak nasza losowa wartość przechowywana w zmiennej randomValueForNothing faktycznie jest pseudolosowa, okazało się natomiast, że miała to być wartość z przedziału 3-8. Nasz kod wymaga małej poprawki.

Co w takim razie musimy zrobić jako programiści? Przejść do dwóch linijek 12 oraz 22 aby zmienić nasz zakres losowania. Co w takim rozwiązaniu jest złego? Konieczność naprawy naszego kodu w dwóch miejscach. A co jeżeli zapomnimy o jednym z nich, albo osoba pracująca z nami nie będzie świadoma takiego rozwiązania?

Tutaj z pomocą przychodzi wzorzec DRY który podpowiada nam, abyśmy się pilnowali i nie powielali kodu, który mógłby zostać napisany tylko w jednym miejscu. Idąc tym tropem piszemy poniższe rozwiązanie.

To czego dokonaliśmy powyżej to dwie rzeczy. Po pierwsze, zredukowaliśmy kod pod względem ilości linijek, po drugie uzależniliśmy jedną metodę od drugiej, co za tym idzie, w przypadku popełnienia błędu sprawi to, że nasz kod będzie musiał zostać naprawiony tylko w jednym miejscu.

Dotarliśmy do końca. Tak jak wspominałem temat niesamowicie prosty, krótki i przyjemny. Przypominam jednak, że nie jest to jedyny wzorzec projektowy, który powinien znać każdy. Serdecznie zapraszam do moich innych wpisów z tej dziedziny (innych oczywiście również). Następny wpis za dwa tygodnie, zbliżają się egzaminy, zaliczenia i muszę skupić się na innych, ważnych rzeczach. Miłego wieczoru!

Your email address will not be published. Required fields are marked *

*