DTO są szeroko stosowane i „rozwiązują” prawdziwe problemy, prawda?

Problemy

• Anemiczny obiekt
• Niespójne dane
• Zduplikowana logika
• Zduplikowana struktura
• Zanieczyszczenie klas
• Naruszenie dotyczące ukrywania informacji
• Kod powtarzany wśród mutatorów , akcesorów , serializatorów , parserów
• Efekt falowania
• Integralność danych

1. Przesyłaj anemiczne dane na tablice.
2. Używaj prawdziwych obiektów biznesowych.
3. Jeśli chcemy przenieść częściowe obiekty: użyj proxy lub obiektów zerowych, aby rozbić graf odniesienia.

Zło

Prawidłowy

Wykrycie

Możemy wykorzystać te same detektory obiektów anemicznych.

Możemy sprawdzić anemiczne klasy bez zachowania obiektów biznesowych (usuwanie serializacji, konstruktorów, mutatorów itp.).

Tagi

• Anemiczny

DTO są narzędziem i ustaloną praktyką w niektórych językach. Powinniśmy z nich korzystać z rozwagą i odpowiedzialnością.

Jeśli musimy rozmontować nasze obiekty, aby odesłać je z naszych królestw, musimy być bardzo ostrożni. Ponieważ rozczłonkowane obiekty nie mają względów integralności.

Jego autor ostrzega nas przed jego nadużyciem.

Relacje

Kod Zapach 01 — Modele anemiczne Zapach kodu 13 — Puste Konstruktory Zapach kodu 20 — Przedwczesnej optymalizacji Kod Zapach 28 — Setery

Więcej informacji

Najlepsze zapachy to coś, co łatwo zauważyć i przez większość czasu prowadzi do naprawdę interesujących problemów. Dobrym tego przykładem są klasy danych (klasy ze wszystkimi danymi i bez zachowania). Patrzysz na nie i zadajesz sobie pytanie, jakie powinno być zachowanie w tej klasie.

Martina Fowlera

Inżynieria oprogramowania Świetne cytaty

Ten artykuł jest częścią serii CodeSmell.

Jak znaleźć śmierdzące części kodu?