Misalkan kita memiliki metode foo(String bar)
yang hanya beroperasi pada string yang memenuhi kriteria tertentu; misalnya, harus huruf kecil, tidak boleh kosong atau hanya memiliki spasi putih, dan harus cocok dengan polanya [a-z0-9-_./@]+
. Dokumentasi untuk metode ini menyatakan kriteria ini.
Haruskah metode tersebut menolak setiap dan semua penyimpangan dari kriteria ini, atau haruskah metode ini lebih memaafkan tentang beberapa kriteria? Misalnya, jika metode awal adalah
public void foo(String bar) {
if (bar == null) {
throw new IllegalArgumentException("bar must not be null");
}
if (!bar.matches(BAR_PATTERN_STRING)) {
throw new IllegalArgumentException("bar must match pattern: " + BAR_PATTERN_STRING);
}
this.bar = bar;
}
Dan metode memaafkan kedua adalah
public void foo(String bar) {
if (bar == null) {
throw new IllegalArgumentException("bar must not be null");
}
if (!bar.matches(BAR_PATTERN_STRING)) {
bar = bar.toLowerCase().trim().replaceAll(" ", "_");
if (!bar.matches(BAR_PATTERN_STRING) {
throw new IllegalArgumentException("bar must match pattern: " + BAR_PATTERN_STRING);
}
}
this.bar = bar;
}
Haruskah dokumentasi diubah untuk menyatakan bahwa itu akan diubah dan diatur ke nilai yang ditransformasikan jika memungkinkan, atau haruskah metode ini dibuat sesederhana mungkin dan menolak setiap dan semua penyimpangan? Dalam hal ini, bar
dapat diatur oleh pengguna aplikasi.
Kasus penggunaan utama untuk ini adalah pengguna yang mengakses objek dari repositori oleh pengenal string tertentu. Setiap objek dalam repositori harus memiliki string unik untuk mengidentifikasinya. Repositori ini dapat menyimpan objek dengan berbagai cara (sql server, json, xml, binary, dll) dan jadi saya mencoba mengidentifikasi penyebut umum terendah yang cocok dengan kebanyakan konvensi penamaan.
foo
fungsi ketat yang ketat dalam argumen apa yang diterimanya, dan memiliki fungsi pembantu kedua yang dapat mencoba untuk "membersihkan" argumen yang akan digunakan foo
. Dengan cara ini, masing-masing metode memiliki lebih sedikit untuk dilakukan sendiri, dan mereka dapat dikelola dan diintegrasikan dengan lebih bersih. Jika menuruni rute itu, mungkin juga akan membantu untuk menjauh dari desain pengecualian-berat; Anda dapat menggunakan sesuatu seperti Optional
sebagai gantinya, dan kemudian memiliki fungsi yang mengkonsumsi foo
pengecualian melempar jika perlu.