DTO banyak digunakan, dan mereka 'memecahkan' masalah nyata, bukan?

Masalah

• Obyek Anemia
• Data Tidak Konsisten
• Logika duplikat
• Struktur duplikat
• Pencemaran Kelas
• Pelanggaran Penyembunyian Informasi
• Kode diulang di antara mutator , accessors, serializers , parser
• Efek riak
• Integritas data

1. Transfer data anemia pada array.
2. Gunakan objek bisnis nyata.
3. Jika kita ingin mentransfer objek parsial: gunakan proxy atau objek null untuk memecahkan grafik referensi.

Salah

Benar

Deteksi

Kita dapat menggunakan detektor objek anemia yang sama.

Kami dapat memeriksa kelas anemia tanpa perilaku objek bisnis (menghapus serial, konstruktor, mutator, dll).

Tag

• anemia

DTO adalah alat dan praktik yang mapan dalam beberapa bahasa. Kita harus menggunakannya dengan hati-hati dan bertanggung jawab.

Jika kita perlu membongkar objek kita untuk mengirimnya menjauh dari alam kita, kita harus sangat berhati-hati. Karena objek yang dipotong-potong tidak memiliki pertimbangan integritas.

Penulisnya memperingatkan kita tentang penyalahgunaan yang sebenarnya.

Hubungan

Code Smell 01 — Anemic Models Code Smell 13 — Empty Constructors Code Smell 20 — Prematur Optimization Code Smell 28 — Setter

Info lebih lanjut

Bau terbaik adalah sesuatu yang mudah dikenali dan seringkali membawa Anda ke masalah yang sangat menarik. Kelas data (kelas dengan semua data dan tanpa perilaku) adalah contoh bagus untuk ini. Anda melihat mereka dan bertanya pada diri sendiri perilaku apa yang seharusnya ada di kelas ini.

Martin Fowler

Rekayasa Perangkat Lunak Kutipan Hebat

Artikel ini adalah bagian dari Seri CodeSmell.

Cara Menemukan bagian Stinky dari Kode Anda