Menjadi seorang mahasiswa IT, saya baru-baru ini diberikan beberapa tinjauan tentang pola desain oleh salah satu guru kami. Saya mengerti untuk apa itu, tetapi beberapa aspek masih terus mengganggu saya.

Apakah mereka benar-benar digunakan oleh sebagian besar programmer?

Berbicara tentang pengalaman, saya memiliki beberapa masalah saat pemrograman, hal-hal yang tidak dapat saya selesaikan untuk sementara waktu, tetapi Google dan beberapa jam penelitian menyelesaikan masalah saya. Jika di suatu tempat di web saya menemukan cara untuk menyelesaikan masalah saya, apakah ini pola desain? Apakah saya menggunakannya?

Dan juga, apakah Anda (programmer) menemukan diri Anda mencari pola (di mana saya seharusnya mencari, by the way?) Ketika Anda memulai pengembangan? Jika demikian, ini tentu kebiasaan yang harus saya mulai rengkuh.

UPDATE: Saya pikir ketika saya bertanya apakah programmer benar-benar menggunakannya, saya bertanya jika ketika Anda memiliki masalah untuk menyelesaikan Anda berpikir "Oh, saya harus menggunakan pola itu".

Ketika saya masih seorang programmer pemula, saya menyukai pola desain. Saya tidak hanya menggunakan pola desain. Saya menyebabkan mereka. Dimanapun dan kapanpun saya bisa. Saya tanpa ampun. Aha! Pola pengamat! Ambil itu! Gunakan pendengar! Proksi! AbstractFactory! Mengapa menggunakan satu lapis abstraksi ketika lima akan melakukannya? Saya telah berbicara dengan banyak programmer berpengalaman dan menemukan bahwa hampir semua orang yang membaca Buku GoF melewati tahap ini.

Pemrogram pemula tidak menggunakan pola desain. Mereka menyalahgunakan pola desain.

Baru-baru ini, saya menemukan bahwa menjaga prinsip-prinsip seperti Prinsip Tanggung Jawab Tunggal dalam pikiran, dan menulis tes terlebih dahulu, membantu pola untuk muncul dengan cara yang lebih pragmatis. Ketika saya mengenali polanya, saya bisa terus mengembangkannya dengan lebih mudah. Saya mengenali mereka, tetapi saya tidak lagi mencoba memaksa mereka pada kode. Jika pola Pengunjung muncul itu mungkin karena saya telah refactored keluar duplikasi, bukan karena saya berpikir sebelumnya tentang kesamaan rendering pohon versus menambahkan nilainya.

Pemrogram berpengalaman tidak menggunakan pola desain. Pola desain menggunakannya.

Apakah seseorang mengenalinya atau tidak, sebagian besar programmer memang menggunakan pola.

Namun pada pekerjaan sehari-hari, seseorang tidak memulai pemrograman dengan pola dalam pikiran - seseorang mengakui bahwa suatu pola telah muncul dalam kode dan kemudian menamainya.

Beberapa pola umum dibuat dalam beberapa bahasa - misalnya, pola iterator di dalam C # dengan foreachkata kunci.

Kadang-kadang Anda sudah tahu pola yang akan Anda gunakan sebagai solusi umum untuk masalah yang dihadapi (katakanlah pola repositori - Anda sudah tahu bahwa Anda ingin merepresentasikan data Anda sebagai koleksi di dalam memori).

Seperti tersirat oleh jawaban pdr terkait: pola desain nama yang diberikan untuk hal-hal yang orang lakukan pula , dimaksudkan untuk membuat lebih mudah bagi orang untuk mendiskusikan hal-hal.

Secara umum, ada baiknya mempelajarinya saat memulai, karena mereka memberi Anda wawasan tentang solusi yang ditemukan orang untuk bekerja, sehingga Anda dapat membangun pengalaman bertahun-tahun, dan coba-coba.

Diskusi tentang memotivasi masalah yang disertakan dengan pola dapat memberi Anda wawasan tentang cara-cara yang baik untuk menyerang masalah Anda di tempat pertama, tetapi kecuali pengetahuan pola Anda memungkinkan Anda mengenali ada solusi terkenal yang ada, Anda masih perlu fokus pada hanya memecahkan masalah dulu.

Jika ternyata menggunakan satu atau lebih pola yang ada lalu hebat, Anda memiliki nama siap pakai yang akan memudahkan orang lain untuk memahami kode Anda.

Secara umum, tidak. Ada kalanya pola muncul dari kode saya, tetapi secara umum, saya tidak mencarinya dan saya tentu tidak mengatakan "Oh, Pola Jembatan akan menyelesaikan masalah saya!".

Ini masalahnya. Sebagian besar pola disalahgunakan dan disalahgunakan tanpa ada orang yang mempertimbangkan apakah itu desain yang baik. Polanya bukan atom. Kode tidak terdiri dari permutasi pola X. Belum lagi bahwa tidak semua pola adalah ide yang baik, atau bahwa beberapa bahasa memiliki solusi tingkat bahasa yang jauh lebih unggul daripada beberapa pola.

ya, kebanyakan programmer yang pernah saya temui menggunakan pola paling umum yang ada, Big Ball of Mud . Mereka biasanya memulai dengan arsitektur yang dirancang dengan baik, tetapi biasanya berakhir di sini, terutama jika mereka mulai berpikir "kita harus menggunakan pola desain" di semua tempat dan refactor tanpa ampun.

apakah anda menggunakannya?

Ya, programmer berpengalaman pasti melakukannya. Anda dapat menghindari menggunakan sebagian besar pola desain (tidak termasuk barang tunggal sederhana) untuk saat ini; tetapi semakin Anda memprogram dan semakin kompleks sistem yang Anda bangun, semakin Anda merasa perlu untuk menggunakan pola desain. Jika Anda masih menghindarinya, Anda akan mulai merasakan sakit ketika Anda harus memperluas sistem Anda dan mengubahnya sesuai persyaratan baru.

Jika di suatu tempat di web saya menemukan cara untuk menyelesaikan masalah saya, apakah ini pola desain?

Belum tentu. Pola desain mengacu pada cara spesifik untuk merancang kelas, perilaku dan interaksinya untuk mencapai tujuan tertentu (atau menghindari masalah tertentu). Apa yang mungkin Anda temui mungkin bukan masalah desain, melainkan urutan langkah-langkah khusus untuk memprogram API tertentu. Misalnya: ada urutan tertentu untuk membuat koneksi soket. Lakukan salah dan soket Anda tidak akan berkomunikasi. Urutan langkah-langkah itu bukan merupakan suatu pola.

apakah Anda (programmer) menemukan diri Anda mencari pola

Iya. Pola desain mewujudkan aksioma "pencegahan lebih baik daripada mengobati". Jika Anda dapat menemukan masalah desain yang akan datang sebelumnya, Anda dapat mencegah desain ulang besar untuk mengakomodasi perubahan nanti. Jadi, perlu mengetahui pola desain sebelumnya dan mencari tempat di mana Anda perlu menggunakannya saat Anda membangun aplikasi Anda.

di mana saya harus mencari btw?

Karena Anda seorang pelajar, Anda mungkin belum melihat masalah khas yang menginspirasi pola desain. Saya sangat menyarankan Anda melihat Pola Desain Kepala Pertama . Mereka pertama kali menghadirkan masalah desain dan kemudian menunjukkan bagaimana pola tertentu dapat memecahkan / menghindarinya.

Pola Desain tidak diajarkan ketika saya masih di sekolah. Dan, untuk sebagian besar karir pemrograman saya, saya telah bekerja dengan kode lama yang berorientasi pada objek. Dalam beberapa tahun terakhir, saya sudah mencoba mempelajarinya karena itu terdengar seperti ide yang bagus. Namun, saya harus mengakui bahwa setiap kali saya mengambil buku atau mencoba membaca tutorial tentang masalah ini, mata saya menjadi sayu dan saya sama sekali tidak belajar sesuatu yang praktis tentangnya.

Saya tidak percaya saya mengakui hal itu di depan umum. Saya pikir saya mungkin baru saja kehilangan kredibilitas geek yang mungkin telah saya bangun selama bertahun-tahun.

Jangan mencari trendiness

Solusi pemrograman standar apa pun untuk masalah tertentu dapat dianggap sebagai pola desain, tidak masalah seberapa populernya mereka, atau jika programmer lain menggunakannya atau tidak.

Anda mungkin sudah menggunakan pola desain yang belum ditemukan / ditentukan.

Jangan coba menggunakannya, coba pikirkan istilah mereka

Masalah dengan pola desain adalah bahwa kadang-kadang programmer ingin menyesuaikan masalah mereka ke dalamnya ketika itu sebaliknya.

Ingat desain konvensi pola memiliki masalah khas untuk dipecahkan, Anda bahkan dapat menggabungkan pola desain untuk mengatasi masalah lain yang lebih besar. Ini semacam tipikal dalam Arsitektur Berorientasi Layanan, lihat saja beberapa pola SOA yang ada .

Cari mereka di alam liar

Ada banyak proyek sumber terbuka di mana Anda akan menemukan pola desain terapan. Salah satu contoh yang terlintas dalam pikiran adalah Joomla: Anda akan menemukan lajang , pengamat . Perpustakaan GUI akan memiliki pola dekorator , pola perintah diimplementasikan, dan mungkin bahkan kelas terbang .

Ada pola lain seperti pola data, misalnya Proyek Doktrin sendiri telah digunakan, pola rekaman aktif (1.x), pola manajer entitas (2.x), unit kerja , repositori , objek kueri , pemetaan metadata , data pemetaan , dan yang lebih umum lainnya seperti pola strategi , dan pola dekorator .

Ada begitu banyak solusi menarik untuk dipilih. Lihat Pola Arsitektur Enterprise Martin Fowler , ada juga pola model data .

Pelajarilah mereka ketika saatnya tiba

Pelajari mereka, kenal mereka, terobsesi terhadap mereka dan ketika saatnya tiba Anda akan tahu bagaimana menyelesaikan masalah pemrograman x, Anda akan menjadi programmer yang lebih baik pada saat itu.

Menjadi seorang arsitek

Saya akan mengatakan bahwa dapat berpikir secara pola untuk menyelesaikan masalah, secara efektif mengubah Anda menjadi seorang arsitek perangkat lunak . Bahkan jika Anda tidak ingin menjadi seorang arsitek perangkat lunak, solusi Anda akan memiliki kualitas yang lebih teknis, lebih bersih dan skalabilitas yang lebih baik — dalam hal desain — secara default.

Saya telah memprogram sekitar 7 tahun dalam C ++ dan mempelajari pola sekitar 2 tahun yang lalu. Sebagian besar pola mungkin memiliki beberapa aplikasi, tetapi dalam penggunaan saya, beberapa lebih baik daripada yang lain. Anda harus berpikir mengapa Anda menggunakannya.

Pola iterator sebenarnya membuat kode saya lebih membingungkan dan telah menambahkan kompleksitas yang tidak perlu. Saya bisa mendapatkan rawatan yang sama menggunakan typedef untuk tipe vektor STL. Dan setiap perubahan yang saya buat untuk kelas yang di-iterasi saya juga harus membuat ke kelas iterator.

Metode pabrik, bagaimanapun, telah sangat berguna, berdasarkan polimorfisme yang disediakannya. Saya lupa siapa yang mengatakannya, tetapi pernyataan "reusability berarti bahwa kode lama dapat menggunakan kode baru", sudah pasti benar dengan pola pabrik.

Saya telah menggunakan pola metode templat selama bertahun-tahun tanpa menyadarinya "pola desain".

Pola Observer telah membantu dalam beberapa kasus, kadang-kadang tidak. Anda kadang-kadang harus memprediksi kompleksitas untuk menentukan apakah kompleksitas overhead dari pola Observer sepadan. Kami memiliki program yang menggunakan sekitar 10 pelanggan dan mungkin ada lebih banyak lagi, sehingga pola pengamat / pelanggan sangat membantu. Namun, program lain memiliki dua tampilan GUI. Saya menerapkan pola pengamat untuk program ini, dan sebagian besar tidak perlu, hanya karena menambah kompleksitas dan saya tidak mengantisipasi menambahkan lebih banyak tampilan.

Saya pikir mereka yang mengatakan untuk selalu menggunakan pola berasumsi bahwa program Anda akan menjadi sangat kompleks, tetapi seperti halnya semuanya, ada titik impas dalam hal kompleksitas.

Menambahkan ke Lunivore. Saya ingin mengutip ini dari buku pertama kepala

        ## **Three steps to great software** ##     

• Pastikan perangkat lunak melakukan apa yang diinginkan pelanggan
• Menerapkan prinsip berorientasi objek yang baik
• Berusaha keras untuk mempertahankan desain yang dapat digunakan kembali

Ini selama tahap ketiga, setelah sistem Anda bekerja sebagaimana mestinya. Saatnya menerapkan pola untuk membuat perangkat lunak Anda siap untuk tahun-tahun mendatang.

Apakah mereka benar-benar digunakan oleh sebagian besar programmer?

Saya kira ya. Di ADO.Net ada kelas DataAdapter untuk memberikan contoh sederhana meskipun tergantung pada bidang apa Anda ingin mengkhususkan pola dapat bervariasi.

Berbicara tentang pengalaman, saya memiliki beberapa masalah saat pemrograman, hal-hal yang tidak dapat saya selesaikan untuk sementara waktu, tetapi google dan beberapa jam penelitian menyelesaikan masalah saya. Jika di suatu tempat di web saya menemukan cara untuk menyelesaikan masalah saya, apakah ini pola desain? Apakah saya menggunakannya?

Tidak, itu bukan pola desain dalam pikiran saya. Pola desain cenderung memiliki beberapa pengaturan kelas dan metode yang menentukan resep pola.

Saya lebih suka memikirkan apa yang Anda lakukan di sana sebagai praktik umum. Waspadalah terhadap pengkodean salin dan tempel.

Dan juga, apakah Anda (programmer) menemukan diri Anda mencari pola (di mana saya seharusnya mencari btw?) Ketika Anda memulai pengembangan? Jika demikian, ini tentu kebiasaan yang harus saya mulai rengkuh.

Kadang-kadang ketika saya melihat kode yang sama berulang-ulang, saya mungkin menemukan cara untuk memperbaiki kode menjadi suatu pola atau jika saya ingat solusi untuk masalah yang sama yang melibatkan pola saya akan mengeluarkannya dan menggunakannya. Head First Design Patterns memiliki lebih dari beberapa pola di dalamnya, sedangkan Refactoring akan menjadi saran untuk praktik pengkodean yang dapat mengarahkan seseorang untuk menemukan berbagai pola. Jika Anda ingin titik awal lain yang memungkinkan, lihat Pola dan Praktik Microsoft .

Pola belajar bukan hanya belajar sesuatu. Anda belajar apa yang dapat Anda lakukan dengan bahasa pemrograman. Saya sendiri belajar banyak tentang pemrograman berorientasi objek hanya dengan mempelajari bagaimana suatu pola bekerja ( pola gabungan dalam kasus ini).

Seperti yang disebutkan oleh Oded, sebagian besar programmer menggunakannya kadang-kadang tanpa menyadarinya. Keindahan pola adalah bahwa Anda dapat mengatasi masalah khusus dengan pola yang telah ditentukan sehingga Anda tidak perlu berpikir banyak tentang hal-hal arsitektur.

Anda akan mempelajari pola saat Anda mulai bekerja dengan proyek yang ada. Ada begitu banyak pola di luar sana untuk Anda pelajari, dan tidak ada gunanya untuk menguasai semuanya karena tergantung pada proyek apa yang sedang Anda kerjakan. Setiap kali Anda bertemu dengannya, pelajari tentang itu untuk melihat bagaimana itu digunakan.