Basis kode kami sudah lama dan programmer baru, seperti saya, cepat belajar melakukannya dengan cara yang dilakukan demi keseragaman. Berpikir bahwa kita harus mulai dari suatu tempat, saya mengambilnya sendiri untuk mereformasi kelas pemegang data sebagai berikut:
- Metode setter yang dihapus dan membuat semua bidang
final
(saya ambil "final
baik" secara aksiomatis). Setter hanya digunakan dalam konstruktor, ternyata, jadi ini tidak memiliki efek samping. - Memperkenalkan kelas Builder
Kelas Builder diperlukan karena konstruktor (yang pertama kali diminta refactoring) mencakup sekitar 3 baris kode. Ini memiliki banyak parameter.
Seperti keberuntungan, rekan satu tim saya sedang mengerjakan modul lain dan kebetulan membutuhkan setter, karena nilai-nilai yang diperlukannya tersedia di berbagai titik dalam aliran. Jadi kodenya tampak seperti ini:
public void foo(Bar bar){
//do stuff
bar.setA(stuff);
//do more stuff
bar.setB(moreStuff);
}
Saya berpendapat bahwa ia harus menggunakan pembangun sebagai gantinya, karena menyingkirkan setter memungkinkan bidang tetap tidak berubah (mereka telah mendengar saya mengomel tentang ketidakberubahan sebelumnya), dan juga karena pembangun memungkinkan pembuatan objek menjadi transaksional. Saya membuat sketsa pseudocode berikut:
public void foo(Bar bar){
try{
bar.setA(a);
//enter exception-throwing stuff
bar.setB(b);
}catch(){}
}
Jika pengecualian itu kebakaran, bar
akan memiliki data korup, yang seharusnya dihindari dengan pembangun:
public Bar foo(){
Builder builder=new Builder();
try{
builder.setA(a);
//dangerous stuff;
builder.setB(b);
//more dangerous stuff
builder.setC(c);
return builder.build();
}catch(){}
return null;
}
Rekan satu tim saya menjawab bahwa pengecualian yang dimaksud tidak akan pernah menyala, yang cukup adil untuk area kode tertentu, tetapi saya yakin tidak ada hutan untuk pohon itu.
Kompromi adalah untuk kembali ke solusi lama, yaitu menggunakan konstruktor tanpa parameter dan mengatur semuanya dengan setter yang diperlukan. Alasannya adalah bahwa solusi ini mengikuti prinsip KISS, yang dilanggar oleh tambang.
Saya baru di perusahaan ini (kurang dari 6 bulan) dan sepenuhnya menyadari bahwa saya kehilangan yang ini. Pertanyaan yang saya miliki adalah:
- Apakah ada argumen lain untuk menggunakan Builder alih-alih "cara lama"?
- Apakah perubahan yang saya usulkan bahkan benar-benar layak?
tapi sungguh,
- Apakah Anda punya tips untuk menyajikan argumen seperti itu dengan lebih baik ketika menganjurkan mencoba sesuatu yang baru?
setA
?