Mari kita ambil contoh lain yang tidak terlalu sarat dengan konsepsi dan harapan. Saya punya enum di sini, dan itu adalah serangkaian prioritas untuk bug.
Nilai apa yang Anda simpan dalam basis data?
Jadi, saya bisa menyimpan 'C'
, 'H'
, 'M'
, dan 'L'
dalam database. Atau 'HIGH'
dan seterusnya. Ini memiliki masalah data yang diketik dengan ketat . Ada satu set nilai valid yang diketahui, dan jika Anda tidak menyimpan set itu dalam database, mungkin sulit untuk bekerja dengannya.
Mengapa Anda menyimpan data dalam kode?
Anda punya List<String> priorities = {'CRITICAL', 'HIGH', 'MEDIUM', 'LOW'};
atau sesuatu yang berpengaruh dalam kode. Ini berarti bahwa Anda memiliki berbagai pemetaan data ini ke format yang tepat (Anda memasukkan semua huruf besar ke dalam basis data, tetapi Anda menampilkannya sebagai Critical
). Kode Anda sekarang juga sulit dilokalkan. Anda telah mengikat representasi basis data gagasan ke string yang disimpan dalam kode.
Di mana pun Anda perlu mengakses daftar ini, Anda harus memiliki duplikasi kode atau kelas dengan sekelompok konstanta. Tak satu pun dari itu pilihan yang baik. Orang juga tidak boleh lupa bahwa ada aplikasi lain yang dapat menggunakan data ini (yang dapat ditulis dalam bahasa lain - aplikasi web Java memiliki sistem pelaporan Crystal Reports yang digunakan dan data pekerjaan batch Perl ke dalamnya). Mesin pelaporan perlu mengetahui daftar data yang valid (apa yang terjadi jika tidak ada yang ditandai dalam 'LOW'
prioritas dan Anda perlu tahu bahwa itu adalah prioritas yang valid untuk laporan?), Dan pekerjaan batch akan memiliki informasi tentang apa yang valid nilai adalah.
Secara hipotetis, Anda mungkin mengatakan "kami adalah toko satu bahasa - semuanya ditulis dalam Java" dan memiliki .jar tunggal yang berisi informasi ini - tetapi sekarang ini berarti bahwa aplikasi Anda digabungkan secara erat satu sama lain dan .jar yang berisi data. Anda harus merilis bagian pelaporan dan bagian pembaruan kumpulan bersama dengan aplikasi web setiap kali ada perubahan - dan berharap rilis itu berjalan dengan lancar untuk semua bagian.
Apa yang terjadi ketika bos Anda menginginkan prioritas lain?
Bosmu datang hari ini. Ada prioritas baru - CEO
. Sekarang Anda harus pergi dan mengubah semua kode dan melakukan kompilasi dan penempatan kembali.
Dengan pendekatan 'enum-in-the-table', Anda memperbarui daftar enum untuk memiliki prioritas baru. Semua kode yang mendapat daftar menariknya dari database.
Data jarang berdiri sendiri
Dengan prioritas, data kunci ke tabel lain yang mungkin berisi informasi tentang alur kerja, atau siapa yang dapat menetapkan prioritas ini atau yang lainnya.
Kembali ke jenis kelamin seperti yang disebutkan dalam pertanyaan sebentar: Jenis kelamin memiliki tautan ke kata ganti yang digunakan: he/his/him
dan she/hers/her
... dan Anda ingin menghindari pengkodean yang keras ke dalam kode itu sendiri. Dan kemudian bos Anda datang dan Anda perlu menambahkan Anda memiliki 'OTHER'
jenis kelamin (untuk membuatnya sederhana) dan Anda perlu menghubungkan jenis kelamin ini dengan they/their/them
... dan bos Anda melihat apa yang dimiliki Facebook dan ... yah, ya.
Dengan membatasi diri Anda pada bit data yang diketik secara ketat daripada tabel enum, Anda sekarang harus mereplikasi string itu di banyak tabel lain untuk menjaga hubungan ini antara data dan bit lainnya.
Bagaimana dengan datastore lain?
Di mana pun Anda menyimpan ini, prinsip yang sama ada.
- Anda dapat memiliki file
priorities.prop
,, yang memiliki daftar prioritas. Anda membaca daftar ini dari file properti.
Anda bisa memiliki database toko dokumen (seperti CouchDB ) yang memiliki entri untuk enums
(dan kemudian menulis fungsi validasi dalam JavaScript ):
{
"_id": "c18b0756c3c08d8fceb5bcddd60006f4",
"_rev": "1-c89f76e36b740e9b899a4bffab44e1c2",
"priorities": [ "critical", "high", "medium", "low" ],
"severities": [ "blocker", "bad", "annoying", "cosmetic" ]
}
Anda dapat memiliki file XML dengan sedikit skema:
<xs:element name="priority" type="priorityType"/>
<xs:simpleType name="priorityType">
<xs:restriction base="xs:string">
<xs:enumeration value="critical"/>
<xs:enumeration value="high"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="low"/>
</xs:restriction>
</xs:simpleType>
Ide intinya sama. Menyimpan data itu sendiri adalah tempat daftar nilai yang valid perlu disimpan dan ditegakkan. Dengan menempatkannya di sini, lebih mudah untuk memberi alasan tentang kode dan data. Anda tidak perlu khawatir untuk secara defensif memeriksa apa yang Anda miliki setiap waktu (apakah ini huruf besar? Atau lebih rendah? Mengapa ada chritical
jenis dalam kolom ini? Dll ...) karena Anda tahu apa yang Anda dapatkan dari datastore adalah persis apa yang diharapkan oleh datastore Anda untuk dikirim sebaliknya - dan Anda dapat meminta datastore untuk daftar nilai yang valid.
Dibawa pulang
Himpunan nilai yang valid adalah data , bukan kode. Anda tidak perlu berusaha untuk DRY kode - tetapi masalah duplikasi adalah bahwa Anda menduplikasi data yang dalam kode, daripada menghormati tempatnya sebagai data dan menyimpannya dalam database.
Itu membuat menulis beberapa aplikasi terhadap datastore lebih mudah dan menghindari memiliki contoh di mana Anda akan perlu menyebarkan segala sesuatu yang tergabung erat dengan data itu sendiri - karena Anda belum menambahkan kode Anda ke data.
Itu membuat pengujian aplikasi lebih mudah karena Anda tidak perlu menguji ulang seluruh aplikasi ketika CEO
prioritas ditambahkan - karena Anda tidak memiliki kode apa pun yang peduli tentang nilai aktual prioritas.
Mampu beralasan tentang kode dan data secara independen dari satu sama lain membuatnya lebih mudah untuk menemukan dan memperbaiki bug saat melakukan pemeliharaan.