Ini adalah pertanyaan yang agak kabur, tetapi itu adalah sesuatu yang saya tidak pernah merasa telah dijawab dengan cara yang memuaskan ketika membaca tentang desain yang tepat.
Secara umum, ketika belajar tentang pemrograman Berorientasi Objek, abstraksi, anjak piutang, dll, cawan suci desain - dan alasan mereka selalu mengklaim Anda menggunakan teknik pengembangan yang dipermasalahkan - adalah bahwa itu akan membuat program Anda "mudah diubah" , "dipelihara", "fleksibel", atau sinonim apa pun yang digunakan untuk mengekspresikan konsep yang terdengar produktif. Dengan menandai ivars pribadi, memecah kode menjadi banyak metode kecil, mandiri, menjaga antarmuka umum, Anda seharusnya mendapatkan kemampuan untuk memodifikasi program Anda dengan mudah dan anggun.
Untuk perubahan yang relatif kecil, ini berhasil bagi saya. Perubahan pada struktur data internal yang digunakan oleh kelas untuk meningkatkan kinerja tidak pernah menjadi kesulitan besar, dan tidak ada perubahan pada akhir antarmuka pengguna, terlepas dari API, seperti mendesain ulang sistem entri teks atau merombak grafik untuk elemen gameplay .
Semua perubahan ini tampaknya bersifat mandiri. Tidak ada yang melibatkan perubahan pada perilaku atau desain komponen program Anda yang dimodifikasi, sejauh kode luar yang bersangkutan. Apakah Anda sedang menulis secara prosedural atau gaya OO, dengan fungsi besar atau kecil, ini adalah perubahan yang mudah dilakukan walaupun Anda hanya memiliki desain yang cukup bagus.
Namun, setiap kali perubahan menjadi besar dan berbulu - yaitu, perubahan pada API - tidak ada "pola" berharga saya yang pernah datang untuk menyelamatkan. Perubahan besar tetap besar, kode yang terpengaruh tetap terpengaruh, dan banyak jam kerja pemijahan bug ada di depan saya.
Jadi, pertanyaan saya adalah ini. Seberapa besar perubahan yang diklaim dapat difasilitasi oleh desain yang tepat? Apakah ada beberapa teknik desain lebih lanjut, baik yang tidak diketahui oleh saya atau yang gagal saya implementasikan, yang benar-benar membuat modifikasi lengket terdengar sederhana, atau apakah janji itu (yang saya dengar dibuat oleh begitu banyak paradigma yang berbeda) hanyalah ide yang bagus, benar-benar terputus dari kebenaran abadi pengembangan perangkat lunak? Apakah ada "alat perubahan" yang dapat saya tambahkan ke toolbelt saya?
Secara khusus, masalah yang saya hadapi yang mengarahkan saya ke forum adalah ini: Saya telah berupaya menerapkan bahasa pemrograman yang ditafsirkan (diimplementasikan dalam D, tapi itu tidak relevan), dan saya telah memutuskan bahwa argumen penutupan saya haruslah berbasis kata kunci, bukan posisional seperti saat ini. Ini membutuhkan modifikasi semua kode yang ada yang memanggil fungsi anonim, yang, untungnya, agak kecil karena saya sejak awal dalam pengembangan bahasa saya (<2000 baris), tetapi akan sangat besar jika saya membuat keputusan ini pada tahap selanjutnya. Dalam situasi seperti itu, apakah ada cara bahwa dengan pandangan ke depan yang tepat dalam desain saya bisa membuat modifikasi ini lebih mudah, atau apakah perubahan tertentu (sebagian besar) secara intrinsik jauh jangkauannya? Saya ingin tahu apakah ini merupakan kegagalan keterampilan desain saya sendiri - jika ya, saya
Untuk lebih jelasnya, saya sama sekali tidak skeptis terhadap OOP atau pola lainnya yang biasa digunakan. Bagi saya, bagaimanapun, kebajikan mereka ada dalam penulisan asli, bukan pemeliharaan, basis kode. Warisan memungkinkan Anda untuk mengabstraksi pola berulang dengan baik, polimorfisme memungkinkan Anda untuk memisahkan kode berdasarkan fungsi yang dipahami manusia (kelas mana) dan bukan oleh efek yang dipahami mesin (cabang switchpernyataan itu), dan fungsi kecil dan mandiri memungkinkan Anda untuk tulis dengan gaya "bottom-up" yang sangat menyenangkan. Namun, saya skeptis dengan klaim fleksibilitas mereka.
foo metarg1: bar metarg2: bazsebagai foo.metarg1_metarg2_(bar, baz). Namun, bahasa saya membuat perubahan yang lebih besar, yaitu parameter berbasis daftar ke parameter berbasis kamus, yang memengaruhi runtime tetapi bukan pengurai, sebenarnya, karena properti spesifik dari bahasa saya, saya tidak akan membahasnya sekarang. Karena tidak ada pemetaan yang jelas antara kata kunci yang tidak berurutan dan argumen posisi, runtime adalah masalah utama.