Apakah pola desain benar-benar penting saat ini?

Saya sedang membaca "Coders at Work" dan telah menghadapi kenyataan bahwa beberapa profesional yang diwawancarai dalam buku ini tidak begitu antusias tentang pola desain.

Saya pikir ada 2 alasan utama untuk ini:

1. Pola desain memaksa kita untuk berpikir dalam istilah mereka. Dengan kata lain, hampir mustahil untuk menemukan sesuatu yang baru (mungkin lebih baik).

2. Pola desain tidak bertahan selamanya. Bahasa dan teknologi berubah dengan cepat; oleh karena itu, pola desain pada akhirnya akan menjadi tidak relevan.

Jadi mungkin lebih penting untuk mempelajari cara memprogram dengan benar tanpa pola tertentu dan tidak mempelajarinya.

Intinya juga adalah bahwa biasanya ketika orang menghadapi masalah dan mereka tidak punya banyak waktu, mereka mencoba menggunakan suatu pola. Ini berarti menyalin dan menempelkan kode yang ada ke proyek Anda dengan perubahan kecil untuk membuatnya bekerja. Ketika tiba waktunya untuk mengubah atau menambahkan sesuatu, pengembang tidak tahu harus mulai dari mana karena itu bukan kodenya dan dia tidak terlalu mengenalnya.

Untuk uang saya, saya pikir semua orang kehilangan titik pola desain. Jarang saya duduk bertanya-tanya pola mana yang harus saya gunakan dalam situasi tertentu. Juga, saya menggunakan sebagian besar pola-pola itu jauh sebelum saya tahu mereka punya nama.

Kekuatan pola desain adalah dalam komunikasi. Jauh lebih cepat bagi saya untuk mengatakan "gunakan Strategi untuk itu" daripada menjelaskan secara rinci apa yang saya sarankan. Jauh lebih mudah bagi kita untuk memperdebatkan manfaat model domain yang gemuk vs skrip transaksi jika kita semua tahu apa arti kedua istilah itu. Dan seterusnya.

Dan yang paling kuat dari semuanya, jika saya telah menamai FooBuilder kelas maka Anda tahu bahwa saya menggunakan pola Builder untuk menghasilkan Foo saya.

Bahkan jika Anda tidak tahu apa yang saya bicarakan ketika saya mengatakan "Pola pengamat sangat ideal untuk itu," Anda akan dapat mematikan dan google dengan cukup mudah.

Dalam hal itu, kekuatan pola desain tidak akan pernah pudar.

Pola desain adalah peningkatan kekuatan ekspresif dari bahasa umum yang kita gunakan sebagai orang perangkat lunak. Bahasa umum ini tidak penting, tetapi membuat banyak solusi umum untuk masalah lebih mudah dan lebih cepat untuk diungkapkan. Sebagai contoh, jauh lebih mudah untuk berbicara tentang Singleton daripada berbicara tentang "kelas-kelas di mana kita seharusnya hanya memiliki satu contoh tetapi yang tidak dapat dibuat statis dan global".

Solusi yang diberikan pola desain berguna, tetapi mereka adalah solusi yang Anda mungkin sudah memikirkan jika Anda menghadapi masalah yang mereka pecahkan. Tingkat kematangan tertentu diperlukan untuk memahami pola desain - jika Anda belum pernah menyelesaikan masalah, Anda tidak akan melihat nilai atau minat pada solusi.

Pola melayani dua tujuan utama:

• Mengatasi ketegangan yang dapat diprediksi : Pola dirancang untuk menyelesaikan serangkaian ketegangan tertentu dengan cara yang diketahui berhasil. Kent Beck, penulis Smalltalk Best Practice Patterns , menggambarkan pola sebagai cara untuk mengulangi keputusan yang akan dibuat oleh seorang pakar dalam situasi yang sama. Selama ketegangan tetap sama (dan sering terjadi), pola yang menyelesaikannya akan tetap bermanfaat.

• Pengganda kekuatan komunikasi : Pola memungkinkan kita untuk berbicara banyak dengan sedikit. Mereka memanfaatkan serangkaian kecil konsep yang kuat dan dipahami dengan baik yang dapat diterapkan di berbagai ruang masalah. @ pdr jawaban sudah mati tentang nilai pola komunikatif.

Saya pikir afirmatif bahwa pola desain menghalangi inovasi adalah sepenuhnya salah. Anda harus tahu di mana saja sudah ada sehingga Anda tidak perlu menemukan kembali roda. Untuk sementara, pola secara keseluruhan berlaku untuk sistem OOP dan tidak terkait dengan platform atau bahasa tertentu.

Sekarang, apa yang saya tidak suka ketika orang berbicara tentang pola adalah bahwa beberapa orang memiliki semacam obsesi terhadapnya. Saya pernah punya klien untuk meminta saya "untuk memasukkan setidaknya dua pola lagi" (WTF ?!) karena karena kurangnya kata kunci dalam kode saya itu tidak terlihat cukup giat.

Mungkin konsep anti-pola erat. Saya tidak berpikir mempelajari pola desain sebagai langkah penting untuk menjadi insinyur perangkat lunak. Desain perangkat lunak itu penting, sering kali dicadangkan sebagai hak prerogatif arsitek perangkat lunak pada suatu proyek, tetapi secara realistis sesuatu yang dapat dipalu dengan konsensus dalam tim "well gelled" pepatah.

Tetapi pola desain dan anti-pola membentuk sumber daya untuk diskusi tersebut. Orang perlu menghargai pelajaran dari hal-hal yang bekerja dengan baik (atau tidak) dan bagaimana memanfaatkan (atau mengurangi) konsekuensi dari pilihan desain. Sebuah tim yang baik dapat menghasilkan kosakata mereka sendiri untuk diskusi seperti itu, tetapi itu benar-benar bukan hal yang buruk untuk merujuk standar de facto yang dikerjakan oleh penulis yang pernah ke sana, melakukannya.

Ada dua macam pola desain:

1. Pola universal , yang lebih banyak tentang bagaimana mengatur program yang kompleks sehingga Anda dapat memahaminya sama sekali. Ini tidak akan hilang, meskipun lebih banyak contoh dari mereka dapat ditemukan.
2. Pola situasional , yang sangat terikat pada kekuatan-kekuatan tertentu yang disebabkan oleh kendala (misalnya, bahasa pemrograman) sehingga ketika kekuatan-kekuatan itu berubah, mereka menjadi tidak relevan.

OK, bisa dibilang semua pola agak situasional, tetapi dengan beberapa kekuatan berasal dari dunia nyata dan dengan yang lain kekuatan dari alat. Alat berubah jauh lebih cepat daripada dunia nyata.

Membaca tentang pola-pola desain seperti belajar matematika alih-alih menciptakannya kembali. Tidak ada yang mencegah Anda membuat kemajuan besar di bidang tertentu begitu Anda memiliki pemahaman yang kuat tentang apa yang terjadi sebelumnya. Apakah Anda pikir Rieman tidak pernah membaca Euclid?

Ada manfaat untuk pola desain ketika mereka mengurangi jumlah waktu yang dihabiskan oleh kolega atau pelanggan Anda dengan berpikir "Bagaimana cara kerjanya?". Meskipun tidak ada gunanya menegakkan standar demi standardisasi, jika ada satu cara umum dan dipahami dengan baik untuk melakukan sesuatu, setiap kali seorang pembuat kode mencari pola yang mengharapkan untuk menemukannya dan melakukannya, Anda telah membuat pekerjaan mereka dan pekerjaan Anda lebih mudah.

Saya percaya bahwa geng empat sendiri mengklasifikasikan pola desain sebagai

solusi umum untuk masalah yang biasa terjadi *

Jadi ya, polanya relevan ketika jenis masalah yang sama terjadi. Dan ini membawa kita ke masalah dengan istilah "Pola Desain". Suatu pola adalah sesuatu yang dapat dikenali yang terjadi berulang kali. Jadi pada kenyataannya tidak ada pola desain, ada pola masalah.

Beberapa bahasa pemrograman mungkin memiliki solusi asli untuk beberapa masalah tersebut. Buku "Pola Desain" itu sendiri menyebutkan bahwa pola pengunjung bernilai kecil jika Anda menggunakan CLOS, karena multi-dispatch didukung secara native oleh CLOS, masalah yang paling penting yang coba dipecahkan oleh pola Pengunjung.

Juga, .NET framework memiliki mekanisme build in event untuk menerbitkan acara ke banyak pendengar, membuat pola Pengamat kurang relevan dalam konteks ini.

Perubahan dari aplikasi desktop ke aplikasi web ** juga mengubah jenis masalah pemrograman yang harus kita pecahkan. Banyak pola dalam buku "Pola Desain" yang relevan untuk aplikasi desktop, tetapi tidak terlalu banyak untuk aplikasi web. Tentu saja, dengan aplikasi satu halaman, pola ini mungkin relevan lagi di sisi klien.

Tetapi pola desain, dan buku-buku seperti "Pola Desain", atau "Pola Arsitektur Aplikasi Perusahaan" sangat berharga ketika Anda seorang programmer pemula dan dihadapkan dengan jenis masalah baru untuk pertama kalinya; karena saya pertama kali saya diminta untuk mengimplementasikan fungsi Undo. Kalau bukan karena buku "Pola Desain", implementasi saya mungkin akan seperti menyimpan snapshot dari data setelah setiap operasi yang berubah negara *** - sangat rawan kesalahan, dan sangat tidak efisien, pendekatan.

Jadi ya, beberapa pola menjadi kurang relevan dari waktu ke waktu, dan ketika Anda menjadi programmer yang berpengalaman, Anda kurang memikirkannya. Tetapi bagi seorang pemula, mereka berharga, selama Anda ingat bahwa mereka adalah sarana untuk memecahkan masalah - dan bukan upaya untuk menggunakan sebanyak mungkin.

* kutipan mungkin tidak 100% akurat karena diambil dari memori

** dalam pengalaman saya, semakin umum bagi perusahaan untuk memilih mekanisme pengiriman web untuk aplikasi lini bisnis internal.

*** setelah mempelajari pemrograman fungsional dan struktur data fungsional, maka itu mungkin sebenarnya cara saya akan menyelesaikannya hari ini.

Ketaatan terhadap pola desain bisa merugikan - pola merupakan solusi terdokumentasi untuk masalah umum, tetapi mereka bukan buku petunjuk. Namun, hanya karena mereka dibahas panjang lebar dan, dalam beberapa kasus, diterapkan di luar domain masalah yang efektif tidak berarti mereka tidak memiliki nilai apa pun. Mereka adalah seperangkat prinsip - menyebutnya kerangka kerja - untuk memanfaatkan ketika merancang arsitektur program, memungkinkan bagi arsitek untuk memberi kesan bagaimana ia ingin melihat solusi bekerja. Tim pengembang yang baik memandang mereka sebagai dasar untuk fungsionalitas, bukan spesifikasi fungsional.