Ketika saya melakukan desain untuk suatu tugas, saya terus berjuang dengan perasaan mengomel ini bahwa selain menjadi garis besar secara umum, hal itu akan sedikit banyak diabaikan pada akhirnya. Saya akan memberi Anda sebuah contoh:
Saya sedang menulis antarmuka untuk perangkat yang memiliki operasi baca / tulis. Masuk akal di diagram kelas untuk memberinya fungsi baca dan tulis. Namun ketika turun untuk benar-benar menulisnya, saya menyadari bahwa mereka secara harfiah memiliki fungsi yang sama dengan hanya satu baris kode yang diubah (read vs write function call), jadi untuk menghindari duplikasi kode saya akhirnya mengimplementasikan fungsi do_io dengan parameter yang membedakan antara operasi. Selamat tinggal desain aslinya.
Ini bukan perubahan yang sangat mengganggu, tapi itu sering terjadi dan bisa terjadi di bagian yang lebih kritis dari program ini juga, jadi saya tidak bisa tidak bertanya-tanya apakah ada titik untuk merancang lebih detail daripada garis besar umum, setidaknya ketika itu datang ke arsitektur program (jelas ketika Anda menentukan API Anda harus mengeja semuanya).
Ini mungkin hanya hasil dari pengalaman saya dalam melakukan desain, tetapi di sisi lain kita memiliki metodologi lincah yang semacam mengatakan "kita menyerah pada perencanaan jauh ke depan, bagaimanapun juga semuanya akan berubah dalam beberapa hari", yang sering kali bagaimana saya merasa.
Jadi, bagaimana tepatnya saya harus "menggunakan" desain?
do_iotampaknya menjadi detail implementasi internal dari kelas itu. Antarmuka publik akan dan mungkin masih harusread(...)danwrite(...)karena jauh lebih banyak tentang maksud panggilan.