Czy "Klasa danych" naprawdę jest zapachem kodu?

Question

Książka Fowlera Refactoring wymienia "Klasa danych" jako zapach kodu. Jednak, gdy jednostka testuje metodę, przekazując obiekty wartości, np. obiekty transferu danych, sprawiają, że testowanie jest znacznie łatwiejsze niż próba ustawienia lub zbadania stanu wewnątrz klasy.

Uderza mnie, że metodologia Test Driven Development opiera się na założeniu, że łatwe do napisania testy wskazują, że interfejs jest czysty, a metoda jest spójna. Metody czysto idepcyjne są najłatwiejsze do przetestowania i najłatwiejsze do ponownego wykorzystania. Dlaczego więc klasa danych jest zła? Zalecaną poprawką jest przeniesienie zachowania do klasy danych, ale dlaczego obiekt wartości wymaga zachowania?

Answer 1

Nie sądzę, że klasy danych są takie same jak obiekty wartości. Obiekty wartości są zwykle niezmienne - jak długość lub pieniądze. "Klasy danych", które odnosi Fowler, wyglądają jak anemiczne modele domenowe - tj. Worki pobierających i ustawiających.

W związku z tym jest w porządku przekazać obiekt wartości do metody, ale zdecydowanie nie anemiczne modele domen. Dzieje się tak, ponieważ metoda będzie miała nieuzasadnioną przewagę nad mutowaniem wielu rzeczy - i najprawdopodobniej narusza wzór jednej odpowiedzialności.

Sprawa z modyfikowalnych klas danych:

w takim przypadku, polecam mający warstwę odwzorowujący Że zmapować udostępniony podmiotom bogatego modelu domeny i vice-versa. Twój kod będzie głównie dotyczył bogatych modeli domen. Pomysł nie polega na zbytnim obciążaniu klas usług zbyt dużą logiką biznesową, ponieważ byłoby to szkodliwe dla ponownego użycia kodu i testowalności. Oczywiście design jest bardziej sztuką - i nie jest tylko czarny i biały. Klasy danych są niezbędne, tak jak powiedziałeś, jako DTO lub wspólne niemodyfikowalne jednostki. Ale solidny projekt oparty na domenie użyłby tych oszczędnie i zminimalizowałby ich foot-print w bazie kodu.