Haruskah ID bisnis entitas yang terkenal diwakili dengan tipe khusus di DDD / OOP?

9

Dalam istilah praktis, ini berarti menggunakan kebiasaan (tidak berubah) di classatas stringatau beberapa jenis primitif lainnya.

Contoh:

Penerbitan: Nomor Buku Standar Internasional.
Keuangan: Nomor Identifikasi Efek Internasional.

Keuntungan:

Dapat memastikan format pengidentifikasi.
Menjadi anggota model kelas satu.

Kekurangan:

Menambahkan gesekan ketekunan (misalnya Kerangka Entitas).
Lebih banyak kode.

— Sarang
sumber

Haruskah Anda menggunakan kelas khusus? Tentu. Haruskah Anda menggunakannya sebagai ID? Sama sekali Tidak :) ID dengan makna bisnis akan menyebabkan masalah di sepanjang jalan.

— Songo

2

@Songo Bagi saya itu adalah argumen bahwa ID harus memiliki semantik nilai , tetapi tipe primitif bukan satu-satunya tipe dengan semantik nilai, sehingga tidak serta merta mengesampingkan kelas imo. Jangan ragu untuk mengirim jawaban yang bersaing karena saya lupa membuat poin itu.

— Ixrec

1

Sebuah pertanyaan lama saya menyentuh masalah ini dengan berbagai pendapat: programmers.stackexchange.com/questions/281827/… Saya pergi dengan membuat tipe dan terus melakukannya.

— Ziv

6

Jika Anda dapat memberikan fungsionalitas yang cukup bermanfaat bagi kelas untuk membenarkan kerumitan tambahan karena tidak menjadi string, maka lakukanlah. Untuk pengidentifikasi seperti ISBN dan ISIN, saya menduga ini bukan masalahnya.

Agar kelas pengenal bermanfaat, saya berharap akan terlihat seperti ini:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

Jika sebaliknya terlihat lebih seperti ini:

class ISIN {
    getString()
    setString()
}

Kemudian saya membuang seluruh kelas, menggunakan string biasa di mana-mana, dan memastikan saya secara konsisten menggunakan "isin" di semua nama variabel yang relevan.

Perhatikan bahwa dalam beberapa bahasa, menambahkan tipe baru hampir tidak memiliki "kompleksitas tambahan" dalam program tipikal, dalam hal ini Anda akan didorong untuk membuat tipe baru bahkan jika itu tidak memiliki fungsionalitas sama sekali. Tetapi ini tidak berlaku untuk sebagian besar bahasa OOP tradisional seperti C ++.

— Ixrec
sumber

6

Saya akan mengatakan pergi untuk itu. Saya berpendapat bahwa keuntungannya melebihi kerugian dalam kasus ini. Kode tambahan cenderung sangat minim dan masalah ketekunan dapat diselesaikan dengan mudah dengan menyediakan semacam konverter antara Kelas baru Anda dan jenis yang diharapkan oleh basis data (Saya belum pernah menggunakan Entity Framework tapi saya tahu ini relatif tidak menyakitkan di Hibernasi).

Salah satu keuntungan yang bisa Anda dapatkan dengan mendefinisikan kelas Anda sendiri adalah bahwa kompiler dapat memastikan bahwa setiap metode yang menginginkan ISBN atau ISIN akan tahu pada waktu kompilasi jika Anda mencoba dan memberikan nilai yang salah. Juga akan jauh lebih sulit untuk secara tidak sengaja menimpa bidang itu di entitas Anda. Kami dapat menghindari kesalahan umum seperti ini sepenuhnya:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

Jika ISBN adalah kelas dan bukan tipe primitif maka kode di atas bahkan tidak dapat dikompilasi, menghemat banyak waktu debug nanti.

— Matt Watson
sumber

1

setter dan getter? Apakah itu tahun 1992?

— Miles Rout