Apakah pola desain pada umumnya merupakan kekuatan baik atau buruk? [Tutup]

Saya pernah mendengar bahwa pola desain adalah yang terbaik sejak irisan roti. Saya juga pernah mendengarnya berpendapat bahwa pola desain cenderung memperburuk "Sindrom Sistem Kedua," bahwa mereka terlalu banyak digunakan, dan bahwa mereka membuat pengguna mereka berpikir mereka adalah desainer yang lebih baik daripada yang sebenarnya.

Saya cenderung lebih dekat dengan bekas kamp, ​​tetapi baru-baru ini saya telah melihat desain di mana hampir setiap interaksi diganti dengan hubungan pengamat, dan semuanya tunggal.

Jadi, mempertimbangkan manfaat dan masalah, apakah pola desain umumnya baik atau buruk, dan mengapa?

Pola desain adalah bahasa , bukan saran untuk menulis program atau kontrak. Penggunaan utama mereka adalah penjelasan posteriori bagaimana komponen atau sistem itu (atau akan) diimplementasikan. Alih-alih membahas terlalu banyak detail, Anda bisa mengucapkan beberapa kata yang dapat menggambarkan implementasi dengan cukup baik bagi pendengar untuk memahami cara kerjanya dan apa yang penting di dalamnya.

Alex: Hei, bagaimana file konfigurasi dibuat?

Bob: Mereka dihasilkan oleh pabrik, yang berada di config.h.

Sekarang Alex tahu bahwa pembuatan file konfigurasi melibatkan persiapan yang tidak sepele, karena jika tidak, pembuatannya tidak akan dimasukkan ke dalam pabrik.

Namun, jika Bob adalah penipu berkepala pola, dan hanya menggunakan pola di sana-sini, Alex tidak bisa mengatakan apa-apa tentang pembuatan konfigurasi, karena Bob menggunakan pabrik di mana-mana. Ini juga akan menyebabkan kompleksitas yang berlebihan dalam program.

Jadi, programkan dulu, lalu cari pola di kode Anda, bukan sebaliknya. Begitulah cara mereka digunakan secara efektif.

Pola desain sangat bagus . Ketika digunakan dengan benar mereka membuat kode lebih mudah dikelola, lebih mudah dibaca dan digunakan. Bagian dari menjadi programmer yang baik adalah mengetahui kapan harus berhenti dan melihat bahwa refactoring lebih lanjut akan lebih besar daripada manfaatnya. Menggunakan pola desain saja tidak membuat seseorang programmer yang baik, tetapi mengetahui kapan dan di mana menggunakannya tidak. Sama seperti hal-hal lain di dunia, pola desain dapat dianggap ekstrem dan disalahgunakan. Saya tahu saya masih mencari (dan akan untuk waktu yang lama) untuk keseimbangan sempurna dalam kode saya di mana setiap pola desain memiliki tujuan dan jatuh ke tempatnya dengan sempurna seperti sepotong puzzle.

Pola desain sangat bagus, jika digunakan dengan benar.

Sangat berguna untuk diingat bahwa ide pola desain berasal dari arsitektur. Arsitektur dapat sangat bervariasi. Namun, ada banyak ide inti yang ada di setiap bangunan. Dengan cara ini, anggap pola sebagai blok bangunan desain. Penting untuk dicatat bahwa tidak setiap bangunan mencakup semua pola arsitektur yang mungkin.

Katakanlah Anda sedang mendesain rumah. Daripada membiarkan pintu depan terbuka ke jalan, Anda menginginkan area terlindung sebelum memasuki rumah, yaitu ruang depan. Area ini akan cocok dengan pola tertentu. Yakni, ia akan memiliki dua pintu masuk, beberapa dinding dan mungkin atap. Perhatikan, polanya tidak menentukan pintu, jendela atau berapa banyak dinding. Dalam sebagian besar implementasi, akan ada dua pintu, empat dinding, dan mungkin jendela. Namun, polanya menggambarkan area tertutup dengan dua pintu masuk. Satu mengarah ke ruang depan itu sendiri dari luar rumah dan yang lain mengarah ke bagian lain dari rumah. Kuncinya di sini, adalah bahwa jika Anda menginginkan ruang depan Anda harus melampirkan area dan menyediakan dua pintu masuk ke area itu.

Masalah khas dengan pola desain dalam pemrograman adalah penggunaan berlebihan dan keyakinan bahwa mereka adalah peluru perak untuk memperbaiki masalah apa pun. Mereka tidak. Mereka adalah cara untuk berkomunikasi dan berpikir tentang ide-ide pemrograman yang berguna. Jika bit sintaksis dari bahasa tertentu adalah batu bata dan mortir, pola menggambarkan cara yang berguna untuk mengatur mereka untuk memenuhi kebutuhan tertentu.

Saya menganggap desain patters lebih dari " saran " daripada kontrak tidak berubah yang mutlak harus diikuti. Mengapa? Justru karena alasan yang Anda sebutkan. Mengikuti pola desain dalam segala hal mengarah pada kekacauan besar kode yang mengalahkan tujuan menggunakan pola di tempat pertama.

Inilah sebabnya saya membenci situs seperti Praktek Java . Tentu beberapa ide bagus, tetapi kemudian penulis memutuskan untuk menulis seluruh program (ditambah kerangka kerja) mengikuti setiap pola desain yang ia sebutkan. Penulis juga menulis setiap artikel dengan kutipan menakutkan yang membuat pembaca berpikir bahwa praktik java yang sebenarnya mengerikan dan harus dihindari seperti wabah.

TL; DR: Gunakan patters desain. Hanya saja, jangan menyalahgunakan mereka

Juga atur utas ini pada SO. Dari pola desain POV lain adalah kode boilerplate untuk mengkompensasi kekurangan metodologi yang digunakan. Saya bukan penggemar merayakan solusi-solusi itu terlalu banyak.

Saya akan lebih suka yang di tengah. Seperti yang ditunjukkan poster itu, pemahaman tentang pola tidak membuat Anda menjadi pengembang yang baik. Di sisi lain, pemahaman akan pola akan membantu Anda menjadi pengembang yang baik.

Memahami hubungan pola dan melihat pola dalam suatu proyek (sementara pada tahap konsepsi) adalah apa yang akan membuat Anda menjadi pengembang yang baik.

Sering dikatakan bahwa pola desain memberikan solusi yang siap pakai untuk masalah pemrograman. Masalah apa yang mereka hadapi? "Bagaimana saya bisa mengubah perilaku objek, tetapi mengisolasi perubahan dari sisa sistem?"

Pola GoF diakui untuk menyediakan isolasi (enkapsulasi) dari sisa sistem, tetapi seringkali sulit untuk mengetahui bagian mana dari sistem yang diberikan variabilitas melalui penggunaan pola desain mereka. Alih-alih mengikuti skema klasifikasi yang mereka usulkan (kreatif, perilaku dan struktural), saya memetakan perbedaan pola dan menghasilkan dua skema lain untuk mengklasifikasikan pola mereka: siklus hidup dan hirarki enkapsulasi komponen.

Seperti yang dapat Anda lihat dari tabel ini untuk hierarki enkapsulasi, pola desain dapat diterapkan pada setiap tingkat komponen. Tetapi apakah itu masuk akal? Apakah komponen perlu menyediakan variasi perilaku pada tingkat enkapsulasi yang diusulkan, dan apakah pola yang tepat digunakan untuk tingkat itu? Jika pertanyaan-pertanyaan ini tidak dijawab dengan benar maka pola desain kemungkinan besar salah diterapkan. Hanya karena poros vertikal dapat dibangun ke kabin mobil tidak menjadikannya ide yang cerdas.

Menggunakan analogi terhadap uang, pola desain harus dianggap sebagai solusi dengan biaya modal tinggi tetapi biaya operasi rendah. Pola desain berharga mahal di muka dalam hal pengkodean ekstra, verboseness, dan bobot konseptual dari tipuan ekstra yang mereka buat. Mereka juga memiliki kecenderungan untuk mengunci aspek-aspek lain dari desain Anda. Misalnya, menggunakan metode templat memaksa Anda memprogram dengan gaya OO yang berat.

Namun, jika Anda perlu menyelesaikan banyak masalah terkait erat yang bervariasi dalam beberapa hal kecil, atau pasti akan perlu memodifikasi sepotong kode dengan banyak cara tertentu di masa depan, biaya di muka dapat sia-sia karena desain pola menambah fleksibilitas ke kode Anda. Modifikasi atau solusi untuk yang kedua dari masalah Anda yang terkait erat akan jauh lebih mudah dengan pola daripada tanpa.

Kedua kubu benar - mereka adalah kekuatan untuk kebaikan jika digunakan dengan benar, kekuatan untuk buruk jika mereka tersebar di semua tempat.

Pola desain dapat memiliki kemampuan menggambar Anda, tetapi hal yang sama berlaku untuk pengkodean secara umum. Sangat mudah untuk tergoda dengan menulis kotak alat pamungkas - Anda hanya harus mengingat YAGNI untuk menghentikan Anda ditarik keluar dari jalur, dapatkan rasakan seberapa banyak struktur yang dibutuhkan aplikasi. IMO ini hanya untuk individu dan tanda pengalaman / penilaian mereka.

Saya pikir datterns desain bukan sesuatu yang Anda terus-menerus mencoba untuk menerapkan kode Anda. Bagi saya ini terutama tentang bahasa umum untuk pengembang. Lebih mudah mengatakan "kita mengikuti pola pembangun" daripada menjelaskan semuanya berulang-ulang.

Saya sedang membaca kembali Pola Arsitektur Aplikasi Perusahaan saat ini, karena saya menemukan banyak kode yang mengikuti salah satu pola dari buku itu. Saya tidak berpikir itu sengaja dipilih untuk mengikuti salah satu pola, tetapi pasti membantu jika Anda bisa mengatakan " ini skrip transaksi " dan semua orang memiliki pemahaman yang jelas apa artinya.

Tetapi saya menyukai gagasan bahwa Anda dapat memilih dari katalog pola yang sudah disiapkan, ketika Anda merancang fungsionalitas baru atau aplikasi baru. Mengapa menemukan kembali segalanya jika ada solusi yang terbukti untuk masalah tertentu?