Apakah pola desain benar-benar penting saat ini?


107

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.


79
Jika menerapkan pola berarti menyalin dan menempelkan kode yang ada, maka Anda mungkin salah melakukannya
Dyppl

9
menggunakan pola desain! = pemrograman pemujaan kargo
jhocking

11
Judul pertanyaan ini dapat diucapkan kembali dengan kata-kata, "Bukankah menciptakan kembali roda benar-benar penting saat ini?"
Eric King

2
Pola desain memaksa kita untuk berpikir dalam istilah mereka - jika Anda membiarkannya. Kesadaran pola memungkinkan saya untuk mempertimbangkan kemungkinan untuk masalah desain yang diberikan. Seringkali itu seperti membaca menu restoran ... "tidak, tidak, menarik, tidak, hmm, a-ha!". Lebih jauh, fitur-fitur bahasa modern sering membuat diagram pola spesifik, yang dikodifikasi beberapa dekade lalu, kuno.
radarbob

Jawaban:


261

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.


55
+1 untuk "Saya menggunakan sebagian besar pola itu jauh sebelum saya tahu mereka memiliki nama." Mereka semua sudah ada sejak lama, hanya tanpa nomenklatur pola. Kembali pada tahun 1991, saya sedang menulis lajang di C, dan menunjukkan satu ke programmer yang lebih berpengalaman yang belum pernah melihatnya dan berpikir itu cukup bagus.
Bob Murphy

8
Namun, pola juga hilang. Pada 1950-an, "panggilan subrutin" adalah pola yang cukup populer. Dalam C, "objek" adalah pola (agak) populer. Keduanya sekarang hampir punah karena mereka diserap dalam bahasa modern dan (dalam kasus subrutin) bahkan ke set instruksi CPU modern.
Jörg W Mittag

9
@ Bob Murphy: Argh Singleton :( :( @ pdr: tepatnya, pola adalah tentang komunikasi tentang pemrograman. Menerapkan pola karena hampir cocok adalah kesalahan terbesar yang bisa dilakukan seseorang, dan oleh karena itu refleksi desain tidak boleh dilakukan dalam hal pola, mereka hanya boleh masuk ke desain ketika harus menjelaskan apa yang Anda pikirkan: "Ini hampir seperti <pola> kecuali bahwa saya telah mengubah ..." Saya pikir bahwa GOF sangat mengakuinya sendiri: polanya dipangkas / disederhanakan visi, mereka perlu disesuaikan dengan situasi tertentu
Matthieu M.

10
@ Jorg: kapan pola "panggilan subrutin" hilang. Menurut Anda apa panggilan metode / fungsi?
Dunk

10
@Dunk: Itu tergantung pada bahasa yang Anda gunakan, tentu saja. Saya tidak tahu bahasa apa yang Anda gunakan, tetapi di semua bahasa yang saya gunakan hari ini, panggilan subrutin adalah fitur bahasa bawaan, bukan pola desain. Namun, dalam C misalnya, pemanggilan metode adalah pola desain, sedangkan di Jawa itu adalah fitur bahasa bawaan.
Jörg W Mittag

32

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.


15

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.


12

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.


3
Pengalaman saya adalah bahwa kode yang ditulis dengan baik sesuai dengan beberapa pola desain justru karena mereka menggambarkan praktik yang baik. Dengan demikian untuk memuaskan klien Anda, itu seharusnya hanya masalah mengetahui mana yang sudah Anda gunakan dan memasukkan nama mereka dalam dokumen. Mudah!
Donal Fellows

1
@Donal Fellows Itulah yang saya lakukan :) Saya akhirnya menemukan pola bercak dan memberi nama mereka, memberikan proyek akhir yang bahagia. Masalah terbesar saya adalah bahwa itu adalah proyek yang sangat, sangat kecil (sekitar satu minggu kerja) dan sangat mudah: membaca data dari format data yang aneh, melakukan beberapa transformasi, membuat grafik data dan memasukkannya ke dalam basis data.
Vitor Py

@Vitor, saya sangat setuju dengan Anda. Saya pribadi mengenal orang-orang yang berpikir bahwa mencari pola desain yang sesuai dengan masalah / skenario Anda adalah ide yang buruk! Mereka lebih suka menciptakan kembali roda. Saya khawatir mereka akan bangun suatu hari dan meminta saya untuk tidak menggunakan kelas Java IO dan menulis handler IO saya sendiri!
CKing

6

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.


3
"Anti-pola" hanyalah eufemisme bertele-tele untuk "buruk".
Michael Shaw

@hardmath "Anti-pola" berarti lebih dari sekadar 'buruk'
GoatInTheMachine

1
@GoatInTheMachine: Saya setuju, itu adalah Komentar pada posting saya. Sementara anti-pola adalah contoh dari apa yang harus dihindari, mereka memiliki ciri khas yang menjadikannya pilihan desain yang menarik. Kadang-kadang secara sadar mengikuti pola-anti, mengetahui kekurangan dan jebakannya, masuk akal.
hardmath

4

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.


Semua pola didefinisikan dengan cara mereka menyelesaikan serangkaian ketegangan tertentu. Selama ketegangannya sama (dan itu sering terjadi, itulah sebabnya mereka polanya ), polanya akan tetap berguna.
Rein Henrichs

@Rein: Tapi kekuatan yang menciptakan ketegangan bisa internal atau eksternal. Bahasa yang berbeda memiliki kekuatan internal yang berbeda (misalnya, pola yang berkaitan dengan antarmuka lebih relevan untuk Java daripada untuk C ++ karena perbedaan ketegangan dalam sistem kelas mereka).
Donal Fellows

Pastinya. Pandangan sekilas melalui Pola Implementasi (buku pola Jawa Kent Beck) menunjukkan distribusi yang merata antara pola tujuan umum dan yang lebih spesifik dengan karakteristik Jawa. Membandingkan buku itu dengan Smalltalk Best Practice Patterns juga mengungkapkan.
Rein Henrichs

3

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?


1

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.


1

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.


-3

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.


2
ini tampaknya tidak menawarkan apa pun subtantisl atas poin yang dibuat dan dijelaskan dalam jawaban sebelumnya
Agas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.