Spośród wszystkich programistycznych praktyk, podejście DRY uchodzi za jedną z najbardziej fundamentalnych zasad programowania. Jak sama nazwa wskazuje, DRY neguje powtórzenia logiki i tym samym motywuje do tworzenia odpowiednich funkcji bądź klas zawierających wyodrębniony fragment kodu.
Zawsze przyjmowałem za pewnik, że to podejście jest bez wad. Dziś z perspektywy czasu muszę przyznać, że to założenie było błędne, ponieważ jak każda rzecz w świecie IT, tak i DRY ma swoje ograniczenia.
W projektach IT jedyną stałą są zmiany :-) Uwzględnienie dodatkowych wymagań zwykle wnosi pewne trudności. Tak jest na przykład w sytuacji, gdy wydzielona wcześniej funkcja musi zostać rozbudowana, aby mogła objąć nowe scenariusze.
Dodatkowa logika ujęta w funkcji, zapewnia jej większą elastyczność, ale również nieuchronnie prowadzi do coraz większej złożoności.
Tą złożoność można dostrzec już w samej nazwie funkcji. Gdy funkcja z wydzielonym kodem zaczyna odpowiadać za większą liczbę przypadków, jej nazwa wytraca swoje pierwotne znaczenie.
W takim przypadku dobranie odpowiedniej nazwy dla funkcji staje się kłopotliwe, ponieważ odpowiada ona za zbyt dużą ilość szczegółów.
Gdy podejście DRY wymyka się spod naszej kontroli, traci na tym nie tylko wydzielona funkcja, ale również każde miejsce w kodzie, które od niej zależy.
Alternatywne podejście dla DRY w swojej istocie sprowadza się po prostu do zwlekania z wyodrębnianiem kodu. Kod projektu może i ma prawo się powtarzać, nie ma w tym nic złego. Warto w tym miejscu zaznaczyć, że logika, która nie została wydzielona do wielokrotnego użycia, jest łatwiejsza w usuwaniu.
Zachęcam również do zapoznania się z poniższymi artykułami, które są powiązane z podejściem DRY:
