Nie powtarzaj się

„ Nie powtarzaj się ” ( DRY ) to zasada tworzenia oprogramowania mająca na celu ograniczenie powtarzalności wzorców oprogramowania, zastąpienie ich abstrakcjami lub stosowanie normalizacji danych w celu uniknięcia redundancji.

Zasada DRY brzmi: „Każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie”. Zasada została sformułowana przez Andy'ego Hunta i Dave'a Thomasa w ich książce The Pragmatic Programmer . Stosują to dość szeroko, obejmując schematy baz danych , plany testów , system kompilacji , a nawet dokumentację . Gdy zasada DRY jest stosowana z powodzeniem, modyfikacja pojedynczego elementu systemu nie wymaga zmiany innych logicznie niepowiązanych elementów. Ponadto wszystkie elementy, które są ze sobą powiązane logicznie, zmieniają się w sposób przewidywalny i jednolity, dzięki czemu są zsynchronizowane . Oprócz stosowania metod i podprogramów w swoim kodzie, Thomas i Hunt polegają na generatorach kodu , automatycznych systemach kompilacji i językach skryptowych , aby przestrzegać zasady DRY we wszystkich warstwach.

Zasada jednego wyboru

Szczególnym przypadkiem DRY jest zasada pojedynczego wyboru . Zostało to zdefiniowane przez Bertranda Meyera jako: „Kiedy system oprogramowania musi obsługiwać zestaw alternatyw, jeden i tylko jeden moduł w systemie powinien znać ich wyczerpującą listę”. Zastosowano go przy projektowaniu Eiffla .

Alternatywy

MOKRY

Pogląd przeciwny do SUCHEGO nazywa się WET, backronim powszechnie używany do pisania wszystkiego dwa razy (alternatywnie pisz za każdym razem , lubimy pisać lub marnujemy czas wszystkich ). Rozwiązania WET są powszechne w architekturach wielowarstwowych, w których programista może otrzymać zadanie na przykład dodania pola komentarza do formularza w aplikacji internetowej. Ciąg tekstowy „comment” może być powtórzony w etykiecie, znaczniku HTML, w nazwie funkcji odczytu, zmiennej prywatnej, DDL bazy danych, zapytaniach i tak dalej. Podejście DRY eliminuje tę nadmiarowość, stosując ramy, które zmniejszają lub eliminują wszystkie te zadania edycyjne z wyjątkiem najważniejszych, pozostawiając rozszerzalność dodawania nowych zmiennych wiedzy w jednym miejscu. Kevin Greer nazwał i opisał tę zasadę programowania.

AHA

Innym podejściem do abstrakcji jest zasada AHA. AHA oznacza unikanie pośpiesznych abstrakcji , opisane przez Kenta C. Doddsa jako optymalizacja pod kątem zmian i unikanie przedwczesnej optymalizacji. i był pod wpływem „preferowania powielania nad niewłaściwą abstrakcją” Sandi Metz .

AHA jest zakorzenione w zrozumieniu, że im głębiej zainwestowaliśmy w abstrakcję oprogramowania, tym bardziej dostrzegamy, że koszt tej inwestycji nigdy się nie zwróci (błąd kosztów utopionych ) . W związku z tym inżynierowie mają tendencję do powtarzania tej samej abstrakcji za każdym razem, gdy zmieniają się wymagania. Programowanie AHA zakłada, że ​​zarówno rozwiązania WET, jak i DRY nieuchronnie tworzą oprogramowanie, które jest sztywne i trudne w utrzymaniu. Zamiast zaczynać od abstrakcji lub tworzenia abstrakcji przy określonej liczbie duplikatów, oprogramowanie może być bardziej elastyczne i solidne, jeśli abstrakcja jest wykonywana wtedy, gdy jest potrzebna, lub gdy sama duplikacja stała się barierą i wiadomo, jak abstrakcja jest potrzebna funkcjonować.

Programowanie AHA zostało pierwotnie nazwane MOIST przez Doddsa, później ponownie przez Daniela Bartholomae i pierwotnie określane jako DAMP przez Matta Ryera. Istniała inna zasada programowania, nazwana już DAMP i opisana przez Jaya Fieldsa, a społeczność sprzeciwiła się używaniu MOIST ze względu na kulturową niechęć do słowa wilgotny . Dodds wezwał do alternatyw na Twitterze i zasugerował DATE jako alternatywę, zanim zdecydował się na sugestię Cher Scarlett dotyczącą AHA.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Don%27t_repeat_yourself&oldid=1140549843 ”