Memilih Pola Desain yang tepat

Saya selalu menyadari pentingnya memanfaatkan pola desain. Saya ingin tahu bagaimana pengembang lain pergi tentang memilih yang paling tepat. Apakah Anda menggunakan serangkaian karakteristik (seperti diagram alur) untuk membantu Anda memutuskan?

Sebagai contoh:

Jika objek terkait, tetapi kami tidak ingin menentukan kelas beton, pertimbangkan Abstrak

Ketika Instansiasi diserahkan kepada kelas turunan, pertimbangkan Factory

Perlu mengakses elemen objek agregat secara berurutan, coba Iterator

atau yang serupa?

Kesalahpahaman utama dalam dunia pengkodean hari ini adalah bahwa pola adalah blok bangunan. Anda mengambil di AbstractFactorysini dan di Flyweightsana dan mungkin Singletondi sana dan menghubungkannya dengan XML dan presto, Anda punya aplikasi yang berfungsi.

Mereka tidak.

Hmm, itu tidak cukup besar.

Pola bukanlah blok bangunan

Itu lebih baik.

Pola adalah sesuatu yang Anda gunakan saat Anda menemukan masalah - Anda memerlukan fleksibilitas yang disediakan oleh pola, atau yang Anda temui ketika Anda membuat sedikit bahasa dalam file konfigurasi dan Anda berkata "tunggu sebentar, berhenti, ini adalah penerjemahnya sendiri yang saya tulis - ini adalah masalah yang diketahui dan diselesaikan, gunakan pola Penerjemah . "

Tetapi perhatikan di sana, bahwa itu adalah sesuatu yang Anda temukan dalam kode Anda, bukan sesuatu yang Anda mulai dengan. Para pembuat Java tidak mengatakan "Oh, kami akan meletakkan Flyweight di Integer" pada awalnya, tetapi lebih menyadari masalah kinerja yang bisa diselesaikan oleh kelas terbang .

Dan dengan demikian, tidak ada "diagram alur" yang Anda gunakan untuk menemukan pola yang tepat. Pola adalah solusi untuk jenis masalah tertentu yang telah ditemui berulang-ulang dan bagian-bagian utama dari itu disuling menjadi Pola.

Memulai dengan Pola adalah seperti memiliki solusi dan mencari masalah. Ini adalah hal yang buruk: itu mengarah pada rekayasa berlebihan dan pada akhirnya tidak fleksibel dalam desain.

Ketika Anda menulis kode, ketika Anda menyadari bahwa Anda sedang menulis sebuah Pabrik, Anda dapat mengatakan "ah ha! Itu adalah pabrik yang akan saya tulis" dan gunakan pengetahuan Anda untuk mengetahui pola Pabrik untuk dengan cepat menulis bagian selanjutnya dari kode tanpa mencoba menemukan kembali pola Pabrik. Tetapi Anda tidak memulai dengan "Saya punya kelas di sini, saya akan menulis sebuah pabrik untuk itu sehingga bisa fleksibel" - karena tidak akan.

Berikut kutipan dari wawancara dengan Erich Gamma (dari Gamma, Helm, Johnson, dan Vissides ): Cara Menggunakan Pola Desain :

Mencoba menggunakan semua pola adalah hal yang buruk, karena Anda akan berakhir dengan desain sintetis — desain spekulatif yang memiliki fleksibilitas yang tidak diperlukan siapa pun. Perangkat lunak saat ini terlalu rumit. Kami tidak dapat berspekulasi apa yang harus dilakukan. Kita harus benar-benar fokus pada apa yang dibutuhkan. Itu sebabnya saya suka refactoring ke pola. Orang-orang harus belajar bahwa ketika mereka memiliki masalah atau bau kode tertentu, seperti orang menyebutnya hari ini, mereka dapat pergi ke kotak alat pola mereka untuk menemukan solusi.

Bantuan terbaik untuk "apa yang harus digunakan, kapan" kemungkinan halaman Wikipedia untuk pola desain perangkat lunak - bagian "Klasifikasi dan daftar" menggambarkan kategori masing-masing pola dan apa fungsinya. Tidak ada diagram alur; deskripsi di sana mungkin yang terbaik yang akan Anda temukan sebagai cuplikan singkat untuk "apa yang harus digunakan, kapan."

Perhatikan bahwa Anda akan menemukan pola yang berbeda di berbagai bidang pemrograman. Desain web memiliki set pola sendiri sementara JEE (bukan desain web) memiliki set pola lain. Pola pemrograman keuangan sangat berbeda dengan pola desain aplikasi UI yang berdiri sendiri.

Jadi setiap upaya untuk membuat daftar semuanya secara inheren tidak lengkap. Anda menemukannya, cari tahu bagaimana menggunakannya dan akhirnya menjadi kebiasaan dan Anda tidak perlu memikirkan bagaimana atau kapan menggunakannya lagi (sampai seseorang meminta Anda untuk menjelaskannya).

Saya bertanya pada diri sendiri:

1. Masalah apa yang saya coba selesaikan?
2. Pola desain perangkat lunak mana (jika ada) yang paling dekat memecahkan masalah yang sama, atau menyediakan jalur logis untuk menyelesaikan masalah saya?
3. Apakah saya memerlukan abstraksi tambahan (dan kompleksitas) yang disediakan oleh pola, atau apakah itu rekayasa berlebihan untuk masalah khusus saya? Bisakah masalah dipecahkan dengan cara yang lebih sederhana, lebih efisien tanpa pola?

Proses memilih pola perangkat lunak tidak berbeda dengan proses memilih struktur data, kecuali bahwa dalam memilih struktur data, Anda akan mengevaluasi kinerja dan karakteristik memori dari masalah Anda, dan memilih struktur data yang paling cocok dengan karakteristik tersebut.