Uti, non abuti
Rozpoczyna się Dżihad. Właściwie, to już trwa od kilku lat, ale zamiast łagodnieć, wciąż przybiera na sile. Brak porozumienia między zwolennikami okienek i miłośnikami pingwina już nikogo nie dziwi, lecz teraz w obozie Linuxa wyodrębniły się niezależne sekty – Ubuntu, Suse, Fedora…
Konflikt przenosi się też na inne płaszczyzny: antyczni wojownicy z Delphi przegrupowują się przed bitwą przeciwko barbarzyńcom z Javy, model kaskadowy zwalcza nowo powstałą grupę ekstremalnych… przykłady można mnożyć w nieskończoność.
Skąd biorą się te zatargi? Dlaczego nawet ludzie o podobnych przekonaniach potrafią pokłócić się o drobny szczegół przyjętej koncepcji?
Jako przykładem posłużę się koncepcją DDD, czyli projektowaniem sterowanym dziedziną. Wielu specjalistów szeroko zachwala tę metodykę na swoich blogach czy na forach. Jednak ciężko nie zauważyć kontrowersji, jakie powstają wokół modelu dziedziny. Z jednej strony stoją projektanci baz danych, którzy na swoich diagramach umieszczają wyłącznie pola, z drugiej – zagorzali przeciwnicy anemicznego modelu dziedziny, nazywający go nawet antywzorcem projektowym.
Czy zatem dodawać metody do klas znajdujących się w warstwie dziedziny, czy nie? Stosować klasy anemiczne, czy się tego wystrzegać? Moim zdaniem, aby poprawnie zaprojektować system informatyczny, należy odrzucić wszelkie przekonania. Zamiast fanatycznie bronić jednej ze skrajnych koncepcji, lepiej kierować się zdrowym rozsądkiem.
Co zatem z metodami w warstwie dziedziny? Moja odpowiedź: używać, nie nadużywać. Jeżeli jakiś obiekt należący do dziedziny wykonuje jakieś czynności, to należałoby zdefiniować dla nich odpowiednie metody, ale po co na siłę wymyślać funkcjonalność dla obiektów, które po prostu są?
