Pola desain adalah alat. Seperti alat, ada dua cara untuk menggunakannya: cara yang benar, dan cara yang salah. Misalnya, jika saya memberi Anda obeng dan paku, dan meminta Anda untuk menggabungkan dua potong kayu, Anda harus meminta saya untuk palu. Palu digunakan untuk paku, sedangkan obeng digunakan untuk sekrup.
Terlalu sering, pola desain diiklankan sebagai One True Way, yang seringkali hanya benar ketika masalah tertentu muncul. Pengembang junior sering seperti anak-anak ketika mereka menemukan sesuatu yang baru untuk dimainkan; mereka ingin menerapkan pola desain itu untuk semuanya . Dan secara inheren tidak ada yang salah dengan itu, selama mereka akhirnya mengetahui bahwa Pola A berlaku untuk Masalah B, dan Pola C berlaku untuk Masalah D. Sama seperti Anda tidak menggunakan obeng untuk menggerakkan kuku, Anda tidak menggunakan alat khusus pola hanya karena itu ada; Anda menggunakan pola karena itu alat (dikenal) terbaik untuk pekerjaan itu.
Sisi lain dari pola adalah anti-pola. Hal-hal yang telah terbukti berulang kali menjadi buruk, biasanya dalam hal waktu eksekusi atau memori. Namun, baik pola dan anti-pola tidak ada gunanya bagi pengembang yang tidak mengerti mengapa mereka ada. Pengembang suka berpikir bahwa apa yang mereka lakukan adalah baru dan inventif, tetapi sebagian besar waktu, mereka tidak. Itu kemungkinan telah dipikirkan sebelumnya. Orang-orang sebelum mereka telah menciptakan pola karena pengalaman.
Tentu saja, pengembang junior sering kali muncul dengan cara baru dalam melakukan hal-hal lama, dan kadang-kadang cara itu lebih baik. Namun, terlalu sering berakhir dengan kasus efek Dunning-Kruger; pengembang cukup tahu untuk membuat program fungsional, tetapi tidak memahami keterbatasan mereka sendiri. Satu-satunya cara untuk melewati ini tampaknya melalui pengalaman, baik positif maupun negatif. Mereka mengabaikan pola karena mereka percaya diri mereka lebih unggul, tetapi tidak tahu bahwa, pada kenyataannya, 10.000 pengembang telah menggunakan desain tertentu, dan kemudian membuangnya karena itu sebenarnya buruk.
Agile mendukung "menyelesaikan sesuatu dengan responsif" dalam hal menyesuaikan dengan cepat dengan kebutuhan klien yang terus berubah. Itu tidak mendukung pola desain atau membenci mereka. Jika suatu pola adalah metode tercepat dan paling dapat diandalkan, maka pengembang harus menggunakannya. Jika suatu pola tertentu akan menghabiskan lebih banyak waktu daripada sekadar "menyelesaikannya," menggunakan sesuatu yang bukan-suatu pola kemungkinan baik-baik saja (dengan asumsi, tentu saja, bahwa kinerja tidak sangat terdegradasi, dll). Jika tidak ada pola yang diketahui dapat ditemukan, mendesain sendiri lebih disukai daripada memberi tahu klien "tidak." Klien, terutama klien yang membayar, biasanya benar.
Siapa pun yang mengklaim bahwa pola adalah The Way, atau mengklaim bahwa pola adalah The Bane Of Existence, salah. Pola adalah alat, yang dimaksudkan untuk diterapkan pada situasi tertentu, dan memiliki berbagai tingkat keberhasilan berdasarkan keadaan. Ini adalah sebuah Kebenaran, yang tidak bergantung pada apakah Anda memilih MVC atau tidak, jika Anda menggunakan Objek Transfer Data, atau tidak, dll. Yang penting adalah menerapkan kode dalam jangka waktu yang cukup singkat, yang berkinerja cukup baik bagi pengguna, dan cukup bebas dari bug logika.
Biasanya , pola akan memungkinkan bentuk desain yang koheren, dan akan tampil lebih baik daripada mengabaikan semua pola yang mendukung penulisan 100% ide asli, tetapi Anda tidak dapat menghindari semua pola. Misalnya, jika y = x + 5, apakah Anda benar-benar akan menulis y = x + (5 * 3 + 15/3) / 4, hanya untuk menghindari pola penulisan x + 5? Tidak, bukan kau. Anda akan menulis y = x + 5, dan beralih ke masalah berikutnya.
Orang-orang menggunakan pola setiap hari, dan itu tidak masalah . Yang paling penting adalah memiliki kode yang berfungsi secara logis, jarang macet, dan ramah pengguna. Tidak ada yang lebih penting dari itu.