Anda akan melanggar prinsip KERING menempatkan logika validasi di mana-mana kode pos digunakan.
Di sisi lain, ketika berhadapan dengan banyak negara dan sistem kode pos yang berbeda, itu berarti Anda tidak dapat memvalidasi kode pos kecuali Anda tahu negara yang dimaksud. Jadi ZipCodekelas Anda juga perlu menyimpan negara.
Tetapi apakah Anda kemudian secara terpisah menyimpan negara sebagai bagian dari Address(yang mana kode pos juga bagian dari), dan bagian dari kode pos (untuk validasi)?
- Jika Anda melakukannya, Anda melanggar KERING juga. Bahkan jika Anda tidak menyebutnya sebagai pelanggaran KERING (karena setiap instance memiliki tujuan yang berbeda), itu masih tidak perlu mengambil memori tambahan, di atas membuka pintu untuk bug ketika kedua nilai negara berbeda (yang secara logis tidak pernah seharusnya menjadi).
- Atau, sebagai alternatif, itu mengarah pada Anda perlu menyinkronkan dua titik data untuk memastikan bahwa mereka selalu sama, yang menunjukkan bahwa Anda harus benar-benar menyimpan data ini dalam satu titik, sehingga mengalahkan tujuannya.
- Jika tidak, maka itu bukan
ZipCodekelas tetapi Addresskelas, yang lagi-lagi akan mengandung string ZipCodeyang berarti kita telah menjadi lingkaran penuh.
Misalnya, saya dapat berbicara dengan analis bisnis tentang Kode Pos alih-alih string yang berisi kode pos.
Manfaatnya adalah Anda dapat membicarakannya saat mendeskripsikan model domain.
Saya tidak mengerti pernyataan mendasar Anda bahwa ketika sebuah informasi memiliki tipe variabel tertentu, Anda entah bagaimana wajib menyebutkan tipe itu setiap kali Anda berbicara dengan seorang analis bisnis.
Mengapa? Mengapa Anda tidak dapat hanya berbicara tentang "kode pos" dan sepenuhnya mengabaikan jenis tertentu? Diskusi seperti apa yang Anda lakukan dengan analis bisnis Anda (bukan teknis!) Di mana jenis properti itu esensial untuk percakapan?
Dari mana saya berasal, kode pos selalu berupa angka. Jadi kita punya pilihan, kita bisa menyimpannya sebagai intatau sebagai string. Kita cenderung menggunakan string karena tidak ada harapan operasi matematika pada data, tetapi analis bisnis tidak pernah mengatakan kepada saya bahwa itu perlu string. Keputusan itu diserahkan kepada pengembang (atau bisa dibilang analis teknis, meskipun dalam pengalaman saya mereka tidak langsung berurusan dengan seluk beluk).
Seorang analis bisnis tidak peduli dengan tipe data, asalkan aplikasi melakukan apa yang diharapkan untuk dilakukan.
Validasi adalah binatang yang sulit untuk ditangani, karena bergantung pada apa yang diharapkan manusia.
Pertama, saya tidak setuju dengan argumen validasi sebagai cara untuk menunjukkan mengapa obsesi primitif harus dihindari, karena saya tidak setuju bahwa (sebagai kebenaran universal) data selalu perlu divalidasi setiap saat.
Misalnya, bagaimana jika ini adalah pencarian yang lebih rumit? Alih-alih pemeriksaan format sederhana, bagaimana jika validasi Anda memerlukan menghubungi API eksternal dan menunggu tanggapan? Apakah Anda benar-benar ingin memaksa aplikasi Anda untuk memanggil API eksternal ini untuk setiap ZipCodeobjek yang Anda instantiate?
Mungkin itu persyaratan bisnis yang ketat, dan tentu saja itu bisa dibenarkan. Tetapi ini bukan kebenaran universal. Akan ada banyak kasus penggunaan di mana ini lebih merupakan beban daripada solusi.
Sebagai contoh kedua, ketika memasukkan alamat Anda dalam formulir, itu biasa untuk memasukkan kode pos Anda sebelum negara Anda. Meskipun menyenangkan untuk memiliki umpan balik validasi langsung di UI, itu sebenarnya akan menjadi penghalang bagi saya (sebagai pengguna) jika aplikasi mengingatkan saya pada format kode pos yang "salah", karena sumber sebenarnya dari masalah ini adalah (misalnya) bahwa negara saya bukan negara yang dipilih secara default, dan dengan demikian validasi terjadi untuk negara yang salah.
Ini adalah pesan kesalahan yang salah, yang mengalihkan perhatian pengguna dan menyebabkan kebingungan yang tidak perlu.
Sama seperti bagaimana validasi abadi bukanlah kebenaran universal, tidak ada contoh saya. Itu kontekstual . Beberapa domain aplikasi memerlukan validasi data di atas segalanya. Domain lain tidak menempatkan validasi yang tinggi dalam daftar prioritas karena kerumitan yang dibawanya bertentangan dengan prioritas aktualnya (misalnya pengalaman pengguna, atau kemampuan untuk awalnya menyimpan data yang salah sehingga dapat diperbaiki, bukannya tidak pernah membiarkannya menjadi disimpan)
Tanggal Lahir: Periksa bahwa tanggal yang lebih besar dari yang ditentukan dan kurang dari hari ini.
Gaji: Periksa lebih besar atau sama dengan nol.
Masalah dengan validasi ini adalah bahwa mereka tidak lengkap, berlebihan atau menunjukkan masalah yang jauh lebih besar .
Memeriksa bahwa kencan lebih besar daripada pikiran berlebihan. Mindate secara harfiah berarti bahwa itu adalah tanggal sekecil mungkin. Selain itu, di mana Anda menarik garis relevansi? Apa gunanya mencegah DateTime.MinDatetetapi membiarkan DateTime.MinDate.AddSeconds(1)? Anda menghargai nilai tertentu yang tidak terlalu salah dibandingkan dengan banyak nilai lainnya.
Ulang tahun saya adalah 2 Januari 1978 (tidak, tapi anggap saja). Tetapi katakanlah data dalam aplikasi Anda salah, dan sebaliknya dikatakan ulang tahun saya adalah:
- 1 Januari 1978
- 1 Januari 1722
- 1 Januari 2355
Semua tanggal ini salah. Tak satu pun dari mereka yang "lebih benar" daripada yang lain. Tetapi aturan validasi Anda hanya akan menangkap salah satu dari tiga contoh ini.
Anda juga telah sepenuhnya menghilangkan konteks tentang bagaimana Anda menggunakan data ini. Jika ini digunakan dalam mis. Bot pengingat ulang tahun, saya akan mengatakan validasinya tidak ada gunanya karena tidak ada konsekuensi buruk khusus untuk mengisi tanggal yang salah.
Di sisi lain, jika ini adalah data pemerintah dan Anda memerlukan tanggal lahir untuk mengotentikasi identitas seseorang (dan kegagalan untuk melakukannya mengarah pada konsekuensi buruk, misalnya menolak jaminan sosial seseorang), maka kebenaran data sangat penting dan Anda perlu sepenuhnya memvalidasi data. Validasi yang diajukan yang Anda miliki sekarang tidak memadai.
Untuk gaji, ada beberapa akal sehat bahwa itu tidak boleh negatif. Tetapi jika Anda secara realistis berharap bahwa data yang tidak masuk akal dimasukkan, saya sarankan Anda menyelidiki sumber dari data yang tidak masuk akal ini. Karena jika mereka tidak dapat dipercaya untuk memasukkan data sensis, Anda juga tidak dapat mempercayai mereka untuk memasukkan data yang benar .
Jika bukan gaji yang dihitung oleh aplikasi Anda, dan entah bagaimana itu mungkin berakhir dengan angka negatif (dan benar), maka pendekatan yang lebih baik akan dilakukan Math.Max(myValue, 0)untuk mengubah angka negatif menjadi 0, daripada gagal validasi. Karena jika logika Anda memutuskan bahwa hasilnya adalah angka negatif, gagal validasi berarti harus mengulang perhitungan, dan tidak ada alasan untuk berpikir bahwa itu akan muncul dengan nomor yang berbeda untuk kedua kalinya.
Dan jika muncul dengan nomor yang berbeda, itu sekali lagi membuat Anda curiga bahwa perhitungannya tidak konsisten dan karenanya tidak dapat dipercaya.
Ini bukan untuk mengatakan bahwa validasi tidak berguna. Tetapi validasi yang tidak berarti itu buruk, baik karena butuh usaha tanpa benar-benar menyelesaikan masalah, dan memberi orang rasa aman yang salah.