Apakah Gang Empat benar-benar menjelajahi "Pola Ruang"?

144

Sejak saya pertama kali belajar tentang pola desain Gang of Four (GoF) , setidaknya 10 tahun yang lalu, saya mendapat kesan bahwa 23 pola ini seharusnya hanya sampel kecil dari sesuatu yang jauh lebih besar yang saya suka menyebutnya Pattern Space . Ruang Pola hipotetis ini terdiri dari semua solusi yang direkomendasikan (diketahui atau tidak diketahui) untuk masalah desain perangkat lunak berorientasi objek umum.

Jadi saya berharap jumlah pola desain yang dikenal dan didokumentasikan akan tumbuh secara signifikan.

Itu tidak terjadi. Lebih dari 20 tahun setelah buku GoF keluar, hanya 12 pola tambahan yang tercantum dalam artikel Wikipedia, yang sebagian besar jauh kurang populer daripada yang asli. (Saya tidak memasukkan pola konkurensi di sini karena mereka membahas topik tertentu.)

Apa alasannya?

Apakah seperangkat pola GoF sebenarnya lebih komprehensif daripada yang saya pikirkan?
Apakah minat untuk menemukan pola baru menurun, mungkin karena mereka ditemukan tidak terlalu berguna dalam desain perangkat lunak?
Sesuatu yang lain

design-patterns object-oriented-design

— Frank Puffer
sumber

49

Pola ada di mana-mana tetapi sering digunakan dengan cara yang hambar dan robot. Karena itu, saya pikir, ide katalog pola menjadi kurang populer.

— usr

6

Ruang desain? Seseorang bawa Mark Rosewater ke sini, stat!

— corsiKa

16

Martin Fowler menerbitkan Pola Arsitektur Aplikasi Perusahaan pada tahun 2003 yang mendokumentasikan sekitar 50 pola, banyak di antaranya masih cukup dapat dikenali dan digunakan dengan baik saat ini, misalnya "Data Mapper", "Plugin", "Lazy Load", "Service Layer", dll.

— Brian Rogers

2

Menjelajahi ruang dari semua pola yang mungkin akan seperti tidak menjelajahi ruang dari pola yang mungkin sama sekali. Anda bisa menjadikan semuanya sebagai pola. Jika Anda membuat semuanya menjadi pola maka tidak ada yang merupakan pola, karena kata kehilangan artinya.

— Semoga membantu

4

@BradThomas: Tentu, seperti dengan pertanyaan paling menarik, orang cenderung memiliki pendapat tertentu. Tetapi opini setidaknya sebagian didasarkan pada fakta, dan saya telah menemukan banyak fakta menarik dalam jawaban untuk pertanyaan ini yang akan membantu diri saya dan mudah-mudahan orang lain untuk memikirkan kembali pendapat mereka dan datang ke yang lebih kuat.

— Frank Puffer

165

Ketika Buku itu keluar, banyak orang berpikir seperti itu, dan ada banyak upaya untuk membuat "perpustakaan pola" atau bahkan "masyarakat pola." Anda masih dapat menemukan beberapa di antaranya:

"Pola Komunitas" , WikiWikiWeb
"Kelompok Studi Pola Desain Kota New York" , Logika Industri
"Katalog Pola" , Grup Hillside

Tapi kemudian...

Apakah minat untuk menemukan pola baru menurun, mungkin karena mereka tidak begitu berguna dalam desain perangkat lunak?

Ini sangat banyak. Inti dari pola desain adalah meningkatkan komunikasi antar pengembang, tetapi jika Anda mencoba untuk menambahkan lebih banyak pola, Anda dengan cepat mencapai titik di mana orang tidak dapat mengingatnya, atau salah mengingatnya, atau tidak setuju tentang seperti apa tepatnya mereka seharusnya terlihat, dan komunikasi adalah sebenarnya tidak membaik. Itu sudah sering terjadi dengan pola GoF.

Secara pribadi, saya akan melangkah lebih jauh: Desain perangkat lunak, terutama desain perangkat lunak yang baik, terlalu beragam untuk ditangkap secara bermakna dalam pola, terutama dalam sejumlah kecil pola yang orang benar-benar dapat ingat - dan mereka terlalu abstrak bagi orang untuk benar-benar mengingat lebih dari segelintir. Jadi mereka tidak banyak membantu.

Dan terlalu banyak orang yang terpikat dengan konsep ini dan mencoba menerapkan pola di mana-mana - biasanya, dalam kode yang dihasilkan Anda tidak dapat menemukan desain aktual antara semua Singleton (yang sepenuhnya tidak berarti) dan Pabrik-Pabrik Abstrak.

— Michael Borgwardt
sumber

50

Pendapat kontroversial: Pabrik abstrak adalah bau kode :)

— MetaFight

66

Pendapat kontroversial, mungkin, tapi pendapat yang sangat penting untuk diungkapkan. Pola desain dalam bahaya menjadi contoh pakaian baru kaisar, di mana kita semua takut untuk mempertanyakan apakah mereka berguna. Sudah selesai dilakukan dengan baik.

— David Arno

18

@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();

— corsiKa

11

" Inti dari pola desain adalah meningkatkan komunikasi antara pengembang " Saya pikir pola desain adalah untuk memecahkan masalah yang biasanya (dan cukup sering mandiri) yang dihadapi oleh pengembang. Standar meningkatkan komunikasi, dan karena fluktuasi (pola yang timbul dari masalah XY, pola yang dianggap anti-pola) banyak yang tidak menganggap pola desain sebagai standar. Pola desain bagus untuk menunjukkan kekurangan fitur bahasa, dan saya percaya desainer bahasa menerapkan perbaikan masalah ini sebelum menjadi pola desain. Namun, jangan menerima kata-kata saya

— Vince Emigh

11

@ Chris Saya tidak mengerti maksud Anda ... Seperti yang saya katakan, GoF mencoba mengatasi kekurangan OO, dan terutama kekurangan C ++ 98 karena ini adalah bahasa pilihan mereka bersama dengan Smalltalk. Mereka benar-benar menulis: "Pilihan bahasa pemrograman itu penting karena memengaruhi sudut pandang seseorang. Pola kami mengasumsikan fitur bahasa level Smalltalk / C ++, dan pilihan itu menentukan apa yang bisa dan tidak bisa diimplementasikan dengan mudah."

— Shautieh

108

Saya mendapat kesan bahwa 23 pola ini seharusnya hanya sampel kecil dari sesuatu yang jauh lebih besar yang saya suka sebut dengan Space Pola.

Ini adalah asumsi mengerikan yang disebarkan oleh programmer neophyte di mana-mana, programmer yang berpikir bahwa mereka dapat menulis sebuah program hanya dengan menyatukan pola perangkat lunak. Tidak berfungsi seperti itu. Jika ada "ruang pola", Anda dapat mengasumsikan bahwa ukurannya efektif tanpa batas.

Pola desain (dalam pengertian GoF) hanya memiliki satu tujuan: untuk mengkompensasi kekurangan dalam bahasa pemrograman yang Anda gunakan.

Pola desain tidak universal atau komprehensif. Jika Anda mengubah ke bahasa pemrograman yang berbeda dan lebih ekspresif, sebagian besar pola dalam buku GoF menjadi tidak perlu dan tidak diinginkan.

— Robert Harvey
sumber

40

"Pola desain (dalam pengertian GoF) hanya memiliki satu tujuan: untuk mengkompensasi kekurangan dalam bahasa pemrograman yang Anda gunakan." Saya terus mendengar ini, tetapi belum melihatnya dibenarkan. Setiap pembenaran yang seharusnya hanya menunjukkan beberapa pola yang lebih mudah diimplementasikan dalam bahasa dengan beberapa fitur - biasanya Pengunjung dan mungkin Singleton - dan membuat sebagian besar pola tidak tersentuh, hanya menyiratkan bahwa mereka juga dapat dibuat berlebihan oleh bahasa yang lebih baik. Tapi bagaimana kita tahu? Fitur bahasa apa yang membuat Pengamat tidak relevan? Rantai Tanggung Jawab? Gabungan?

— Jules

56

@Jules Fungsi kelas satu saja menghilangkan sebagian besar dari mereka, termasuk Chain of Responsibility (itu hanya komposisi daftar fungsi). Pemrograman reaktif fungsional menghilangkan pola Pengamat. Pola Komposit hanya definisi monoids yang tidak ditentukan secara ketat, dan bahasa dengan typeclasses dan fokus pada hukum aljabar memberikan alat yang kuat untuk bekerja dengan monoids. Saya bisa daftar lebih banyak tetapi Anda mendapatkan ide.

— Jack

12

@ Jules: Saya percaya buku GoF asli mencantumkan iterator sebagai sebuah pola, tapi sekarang transformasi ke fitur bahasa pada dasarnya lengkap dalam setiap bahasa OOP jarak jauh.

— Kevin

9

@RubberDuck bagaimana pola sudah diterapkan membuat pola usang? Ini masih pola desain yang diterapkan. Kumpulan fitur bahasa yang berbeda mungkin menyebabkan implementasi pola yang berbeda, tetapi pola itu sendiri masih ada. Ada pola untuk mempermudah komunikasi dengan memberi nama pada strategi yang sering digunakan. Point in case, kelas .NET disebut ObservableSomething<T>yang membuatnya mudah untuk memahami tujuan mereka, karena menggunakan nama pola yang dikenal umum. Pola adalah ide, bukan implementasi yang tepat.

— null

29

@ Jules: Apa itu Program? Solusi untuk masalah yang muncul kembali. Apa itu Pola Desain? Solusi untuk masalah yang muncul kembali. Mengapa ini bukan program? Karena kami tidak dapat mengungkapkannya sebagai program. Ergo, Pola Desain adalah solusi untuk masalah yang muncul kembali yang seharusnya menjadi Program, bukan Pola Desain, tetapi tidak bisa menjadi Program, karena bahasa tidak cukup ekspresif untuk mengekspresikan Program. Contoh: belum lama ini, "Panggilan Subroutine" adalah Pola Desain! Saat ini, ini adalah fitur bahasa.

— Jörg W Mittag

61

Saya pikir ada tiga faktor yang berperan di sini.

Kurangnya Massa Kritis

Pertama, suatu pola pada dasarnya sedikit lebih dari sekedar memberi nama pada beberapa kode yang mengimplementasikan fungsi tertentu. Satu-satunya cara nama itu memberikan banyak nilai nyata adalah jika Anda dapat bergantung pada semua orang yang tahu apa artinya nama itu hanya dengan menggunakan namanya, mereka segera mengerti cukup banyak tentang kode tersebut.

Pola tidak pernah membentuk massa kritis yang mereka butuhkan untuk mencapai itu. Sebaliknya, AAMOF. Dalam 20 (atau lebih) tahun sejak buku GoF keluar, saya cukup yakin saya belum melihat selusin percakapan di mana semua orang yang terlibat benar-benar tahu pola desain yang cukup untuk digunakan mereka untuk meningkatkan komunikasi.

Untuk membuatnya sedikit lebih aneh: pola desain gagal secara khusus karena gagal.

Terlalu Banyak Pola

Saya pikir faktor utama kedua adalah bahwa, jika ada, mereka awalnya menyebutkan terlalu banyak pola. Dalam banyak kasus, perbedaan antara pola cukup halus sehingga hampir tidak mungkin untuk mengatakan dengan kepastian nyata apakah suatu kelas tertentu cocok dengan satu pola atau yang lain (atau mungkin keduanya - atau mungkin tidak keduanya).

Maksudnya adalah agar Anda dapat berbicara tentang kode di tingkat yang lebih tinggi. Anda dapat memberi label sejumlah kode yang cukup besar sebagai implementasi dari pola tertentu. Cukup dengan menggunakan nama yang telah ditentukan itu, semua orang yang mendengarkan biasanya tahu sebanyak mereka peduli dengan kode itu, sehingga Anda dapat beralih ke hal berikutnya.

Kenyataannya cenderung hampir sebaliknya. Katakanlah Anda sedang rapat dan beri tahu mereka bahwa kelas khusus ini adalah Fasad. Separuh orang dalam rapat itu tidak pernah tahu atau sudah lama lupa persis apa artinya itu. Salah satu dari mereka meminta Anda untuk mengingatkannya tentang perbedaan persis antara Facade dan, katakanlah, Proxy. Oh, dan beberapa orang yang benar-benar tahu pola menghabiskan sisa pertemuan memperdebatkan apakah ini benar-benar harus dianggap sebagai Fasad atau "hanya" Adaptor (dengan satu pria masih bersikeras bahwa sepertinya Proxy baginya).

Mengingat bahwa maksud Anda benar-benar hanya untuk mengatakan: "kode ini tidak terlalu menarik; mari kita beralih", mencoba menggunakan nama pola hanya menambah gangguan, bukan nilai.

Kurang minat

Kebanyakan pola desain tidak benar-benar berurusan dengan bagian kode yang menarik. Mereka berurusan dengan hal-hal seperti: "bagaimana cara membuat objek ini?", Dan "bagaimana saya membuat objek ini untuk berbicara dengan yang itu?" Menghafal nama-nama pola untuk ini (dan juga argumen yang disebutkan di atas tentang detail dan semacamnya) hanya memasukkan banyak energi ke dalam hal-hal yang tidak dipedulikan oleh kebanyakan programmer.

Singkatnya: pola berurusan dengan hal-hal yang sama antara banyak program - tetapi yang benar-benar membuat program menarik adalah bagaimana hal itu berbeda dari program lain.

Ringkasan

Pola desain gagal karena:

Mereka gagal mencapai massa kritis.
Perbedaan antara pola tidak cukup untuk menjamin kejelasan.
Mereka sebagian besar berurusan dengan bagian-bagian kode hampir tidak ada yang benar-benar peduli.

— Jerry Coffin
sumber

2

"... tapi yang benar-benar membuat sebuah program menarik adalah bagaimana itu berbeda dari program lain." Saya sepenuhnya setuju tetapi untuk itu Anda harus terlebih dahulu mendapatkan bagian yang sama dengan benar, mungkin mereka hanya berbeda oleh beberapa aspek sepele. Jika Anda sedikit santai, perlu menyebutkan dan mengidentifikasi pola. Saya yakin orang melihat pola hampir di semua tempat. Hanya saja mereka hampir tidak pernah datang dalam bentuk murni mereka tetapi selalu lebih atau kurang disesuaikan dengan masalah yang dihadapi.

— Trilarion

5

Jawaban yang sangat bagus

— Robert Harvey

4

@Trilarion: Oh, saya sadar bagian-bagian kode itu harus ditulis. Mereka sedikit seperti, katakanlah, ban pada mobil Anda. Anda sangat membutuhkan ban untuk dikendarai sama sekali - tetapi kebanyakan orang masih belum tahu merek ban pada mobil mereka. Ini meminta mereka mempelajari terminologi khusus untuk ban dengan alur diagonal asimetris. Siapa tahu - mereka mungkin telah menyelamatkan hidup saya satu kali, tetapi saya masih tidak menghabiskan hidup saya untuk belajar nama mereka.

— Jerry Coffin

3

@ DavidVicherby: Oke, kalau begitu mari kita gunakan versi analogi "sisi produsen". Apakah penting bahwa John yang mendesain ban untuk Goodyear menggunakan satu kata untuk jenis alur itu, tetapi Pierre yang bekerja untuk Michelin menggunakan kata yang sama sekali berbeda? Apakah penting bahwa seseorang menggunakan kata yang merujuk hanya pada alur, tetapi yang lain kata yang merujuk pada ban lengkap dengan alur horizontal di satu sisi tengah dan alur diagonal di sisi lain?

— Jerry Coffin

2

@ Imibis: Saya akan mengatakan sebagian besar ya, mereka telah gagal. Menurut saya, ada kurang dari setengah lusin pola yang dikenali sebagian besar programmer. Singleton terkenal, tetapi sebenarnya jarang diterapkan (paling-paling). Nama "Pabrik" sudah umum digunakan jauh sebelum "pola" datang (saya ingat penggunaannya pada akhir tahun 1970 atau sangat awal 1980-an). Pola seharusnya membentuk kosakata, tetapi saat ini hampir seperti kosakata saya dalam bahasa Yunani - cukup untuk (mungkin) membuat saya dalam masalah, tetapi tentu saja tidak cukup untuk memesan dari menu, apalagi mengadakan percakapan yang bermakna.

— Jerry Coffin

35

Pola adalah abstraksi yang hilang, pola sederhana diabstraksikan, pola kompleks tidak dikenali, sehingga pola tidak berguna (kecuali beberapa yang tingkat tinggi).

Saya pikir Paul Graham mengatakan yang terbaik:

Ketika saya melihat pola dalam program saya, saya menganggapnya sebagai masalah. Bentuk program harus mencerminkan hanya masalah yang perlu dipecahkan. Keteraturan lain dalam kode adalah pertanda, setidaknya bagi saya, bahwa saya menggunakan abstraksi yang tidak cukup kuat - sering kali saya menghasilkan ekspansi makro yang perlu saya tulis sendiri.

Ketika Anda mengenali pola dalam kode Anda, itu berarti sesuatu berulang sendiri dan Anda harus menggunakan abstraksi yang lebih baik. Jika Anda tidak memiliki abstraksi yang lebih baik, Anda menggunakan pola sebagai solusinya. Karena bahasa pemrograman yang lebih baru memberikan abstraksi yang lebih baik, pola menjadi jauh lebih tidak berguna.
Juga pola-pola sederhana seringkali mudah diabstraksi dan pola-pola kompleks jarang dikenali.
Ketika suatu pola digantikan oleh abstraksi, itu tidak berarti bahwa konsep di balik pola tersebut menghilang, tetapi bahwa konsep tersebut dapat ditulis secara eksplisit dan bukannya tidak langsung dan bahwa itu tidak lagi istimewa dibandingkan dengan kode lain dan menjadi tidak lagi dikenal sebagai sebuah pola.

— Siphor
sumber

2

Secara pribadi, entah bagaimana saya sangat menyukai ide ini. Tetapi kemudian, kode harus dapat dibaca oleh manusia dan orang-orang menyukai pola. Pola membantu kita menemukan jalan kita. Menghapus semua pola dari kode kami akan membuatnya tidak dapat dibaca.

— Frank Puffer

2

@ Sejujurnya saya pikir dari mana PG berasal adalah bahwa sebuah pola adalah 'bau' dari fungsi dasar yang dapat Anda abstraksi, & fakta bahwa Anda belum menariknya ke dalam fungsi atau makro adalah apa yang menyebabkan pengulangan - seperti jika Anda tidak memiliki String.replacefungsi, Anda bisa membayangkannya muncul sebagai suatu pola, tetapi lebih baik menulisnya sekali daripada terus mengimplementasikannya kembali. Setuju bahwa jika Anda tidak memberi nama hal-hal ini dengan benar, itu akan membuatnya lebih sulit untuk dibaca, tetapi ketika dilakukan dengan benar, kode membaca IMO secara lebih deklaratif (misalnya getOrElsegaya monad opsi vs pengecekan nol)

— anotherdave

11

Kutipan Paul Graham tentang menjaga solusi Anda KERING, yang berbeda dari gagasan "pola" GoF. Gagasan GoF adalah tentang memberi nama pada solusi yang umum digunakan. Kami sudah melakukan itu jauh sebelum GoF menerbitkan buku mereka. Misalnya, saya dapat memberi tahu rekan kerja saya bahwa saya akan menggunakan antrian , dan rekan kerja saya segera tahu apa yang saya bicarakan tanpa harus menjelaskan detail apa yang dilakukan antrian atau bagaimana cara kerjanya. Tapi, lihat jawaban luar biasa Michael Borgwardt, di atas.

— Solomon Slow

10

Menurut pendapat saya, jawaban ini salah paham pola apa. Pola desain adalah solusi yang sering ditemui untuk masalah umum. Ini bukan duplikasi kode. Katakan, ambil iterator. Anda memecahkan masalah mengabstraksi wadah sehingga Anda dapat pergi melalui elemen di dalamnya terlepas dari apa wadah itu. Dengan demikian Anda membuat kelas iterator yang melakukan itu untuk masing-masing wadah Anda dan membuatnya menerapkan antarmuka umum. Apa yang abstrak di sini? Sebuah iterator sudah merupakan abstraksi. Dan, tentu saja, ini diterapkan secara berbeda untuk semua kontainer, jadi tidak ada duplikasi kode.

— Malcolm

3

Bagian penting dari kutipan Graham adalah sering kali saya menghasilkan ekspansi makro yang perlu saya tulis sendiri. Ini referensi khusus Lisp macro. Hanya ada begitu banyak abstraksi yang bisa dilakukan tanpa makro.

— Bart van Nierop

13

Sementara saya sebagian besar setuju dengan apa yang orang lain jawab di sini, saya pribadi berpikir bahwa alasan utama untuk tidak bertambahnya jumlah pola adalah bahwa pola kehilangan maknanya ketika ada yang tak terhitung jumlahnya. Yang menyenangkan dengan beberapa pola ini adalah, mereka mencakup banyak domain bermasalah dengan cara standar. Jika Anda akan fokus pada domain pola tak berujung Anda akan berakhir tanpa pola sama sekali. Ini agak seperti "berapa lama garis pantai sebuah pulau?". Jika Anda mengukur pada peta Anda datang dengan angka yang layak. Tetapi jika Anda mencoba untuk mendapatkan yang lebih tepat dan mencapai resolusi yang lebih baik, Anda akan menemukan bahwa panjangnya semakin bertambah hingga tak terbatas (atau ketidakpastian; bagaimana Anda mengukur batas yang tepat dengan pasang surut dan pada tingkat atom?).

— qwerty_so
sumber

1

Benar, pola hanya bisa bekerja jika jumlahnya tidak terlalu banyak. Tapi mengapa yang GoF masih yang paling populer? Beberapa dari mereka sekarang dianggap sebagai antipattern oleh banyak orang (Singleton, Builder, dll.). Ini akan memberi ruang bagi pola baru yang lebih bermanfaat tanpa menambah jumlah total.

— Frank Puffer

2

Saya kira itu seperti 10 perintah. Sumber hanya berjarak 2 karakter (GOF, GOE, GOD) xD

— qwerty_so

9

Ya, dan kadang-kadang sepertinya rekayasa perangkat lunak modern terkait dengan GoF seperti skolastik abad pertengahan berkaitan dengan Aristoteles.

— Frank Puffer

11

Sesuatu yang tidak disebutkan oleh jawaban lain yang juga relevan:

Munculnya bahasa yang diketik secara dinamis.

Ketika buku itu pertama kali keluar ada diskusi serius bahwa Jawa terlalu lambat untuk melakukan pekerjaan nyata. Sekarang Jawa sering digunakan lebih dari bahasa ekspresif karena kecepatannya. Mungkin Ruby, Python, JavaScript, dkk masih terlalu lambat untuk beberapa kelas aplikasi yang penting, tetapi pada umumnya mereka cukup cepat untuk sebagian besar tujuan. Dan setidaknya JavaScript semakin cepat meskipun memiliki lebih banyak fitur yang dikemas dalam setiap rilis.

Buku GoF asli memiliki pola di smalltalk dan c ++, dan jika ingatanku, pola selalu lebih pendek di smalltalk dan kadang-kadang secara signifikan. Beberapa fitur dari pola desain klasik benar-benar cara untuk menambahkan fitur dinamis ke sistem yang diketik secara statis (seperti AbstractFactory yang sudah dibahas, di mana Anda membuat kelas yang benar berdasarkan pada data runtime). Yang lain jauh lebih pendek dalam bahasa dinamis sehingga mereka hanya berbaur dengan penggunaan bahasa itu sendiri.

— Jared Smith
sumber

10

Itu memang terjadi. Lusinan jika tidak ratusan buku diterbitkan dalam apa yang tampak seperti upaya untuk mengurangi seluruh ilmu komputer menjadi pola desain, karena penerbit dan penulis berusaha untuk melompat (atau membuat) kereta musik lain. Saya punya rak mereka. Tidak pernah berkonsultasi sejak pemindaian pertama, dan ya saya payah, karena hanya ada sedikit atau tidak ada sama sekali penggunaan aktual atau yang belum diketahui dengan baik (lihat misalnya Jenis Objek, yang tidak lebih dari bentuk normal ketiga yang diekspresikan di atas selusin halaman alih-alih satu paragraf), dan karena jelas semakin sedikit polanya semakin baik: titik yang menghindari sebagian besar praktisi. Memang, ketika saya memposting bantahan dari Object Type, saya diperintahkan untuk menyusun kembali teks saya sebagai pola desain.Kisah nyata. Yang juga menunjukkan kekurangan lain dari proyek: tidak ada ulasan atau pengecualian atau mekanisme penolakan.

Faktanya, GoF tidak benar-benar berusaha 'mengeksplorasi Pola Desain secara menyeluruh'. Sebaliknya, mereka terlibat dalam proyek yang jauh lebih besar: untuk memperkenalkan 'bahasa pola' ke dalam CS, dengan semua arcana notasi yang aneh tentang Pasukan, Peserta, dll., Yang gagal, karena secara fundamental disalahpahami, dan juga tidak ada gunanya.

Apa yang mereka lakukan , yang bermanfaat, adalah dua hal:

mempublikasikan beberapa trik bermanfaat seperti pola Pengunjung
memberikan seperangkat nama standar yang sebagian besar macet: Pabrik, Adaptor, Iterator, ... Jika Anda melihat CORBA, yang dirancang segera sebelumnya, Anda akan melihat nilainya: semua jenis nama 'asing' seperti Interceptor , Hamba, Pialang, ...

Konsep lain yang bermanfaat yang muncul adalah 'anti-pola', misalnya 'log and throw'. Proyek ini, seperti banyak mode di CS, tergelincir oleh penginjilannya sendiri dan diadopsi secara salah sebagai agama CS lainnya, dan ia berjalan seperti kebanyakan agama seperti itu: berguna dalam beberapa bagian, tetapi tentu saja 'tidak ada peluru perak' ((c ) Fred Brooks, 1965). Sedih karena kita harus terus menemukan kembali itu setiap beberapa tahun benar-benar.

— pengguna207421
sumber

Apakah masih menyedihkan jika menghasilkan diskusi ini (dan semua yang melibatkan)

— r3wt

1

@ r3wt Non sequitur. Yang saya katakan menyedihkan adalah kelemahan industri TI untuk berpikir bahwa setiap perkembangan baru akan menjadi peluru perak mitis, dan kebetulan untuk menghancurkan beberapa pekerjaan sebelumnya sendiri.

— user207421

2

melihatnya dari perspektif yang berbeda. Tidak sedih bagi saya membaca jawaban Anda, belajar untuk tidak mengulangi kesalahannya. jadi apa yang Anda anggap remeh sebenarnya sangat bermanfaat bagi orang lain.

— r3wt

6

Ada beberapa buku berjudul PLoP ( Pola Bahasa Desain Program ) yang masing-masing merupakan antologi makalah yang dipresentasikan pada konferensi tahunan .

Membaca buku, saya menemukan beberapa pola yang menarik dan baru bagi saya, beberapa di antaranya standar (misalnya "setengah objek plus protokol").

Jadi tidak, koleksi GoF tidak lengkap, dan menginspirasi / menginspirasi orang untuk mengumpulkan / menggambarkan / menemukan / menemukan yang baru.

"Hanya 12 pola tambahan yang tercantum dalam artikel Wikipedia" mungkin juga bukan koleksi lengkap: yaitu ada yang lain yang didokumentasikan di tempat lain, misalnya dalam buku-buku PLoP dan mungkin di tempat lain juga.

— ChrisW
sumber

Ya, Anda dapat menemukan deskripsi ratusan pola jika Anda mencarinya. Tapi tak satu pun dari ini tampaknya menjadi sepopuler yang GoF.

— Frank Puffer

Itu karena saya suka membaca buku GoF yang saya baca lebih banyak (buku) ketika mereka diterbitkan (nanti).

— ChrisW

1

@ Frankpuffer Saya yakin polanya populer, walaupun namanya tidak.

— bekerja

5

Buku Gang of Four (GoF) berisi sebagian besar pola yang dimiliki oleh programmer yang berpengalaman dalam bahasa yang tidak fungsional di sabuk alat mereka. Ini seperti seperangkat alat dasar yang semua pembangun tahu cara menggunakannya. Kontribusi utama buku ini adalah untuk memberikan nama yang jelas untuk pola-pola yang umum digunakan oleh programmer yang paling berpengalaman pada saat itu dan karenanya membantu komunikasi antara programmer membahas opsi desain.

Anda berharap bahwa seorang tukang listrik memiliki beberapa alat yang tidak dimiliki oleh pembangun normal, Anda juga akan berharap bahwa seorang programmer WPF mengetahui pola desain untuk "Dependency Properties", atau "SQL Programmer" untuk mengetahui pola desain untuk menggunakan pemicu untuk buat data audit.

Namun kami tidak menganggap ini sebagai "Pola desain" karena mereka hanya digunakan dengan satu teknologi.

Beberapa buku pola desain modem lainnya adalah "Refactoring, Meningkatkan Desain Kode yang Ada (Martin Fowler)" dan "Kode Bersih: Buku Pegangan Pengerjaan Perangkat Lunak Agile (Robert C. Martin) " Kedua buku ini menyajikan konten sebagai transformasi yang Anda buat untuk kode Anda saat ini, alih-alih sebagai "desain yang dapat digunakan kembali kaleng", namun mereka juga "pola desain".

— Ian
sumber

3

Berikut adalah wawancara dengan Erich Gamma di mana ia merefleksikan pilihan pola mereka dan apa yang akan mereka ubah hari ini (nah hari ini 10 tahun lalu, haha).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Bagaimana Anda akan refactor "Pola Desain"?

Erich: Kami melakukan latihan ini pada tahun 2005. Berikut adalah beberapa catatan dari sesi kami. Kami telah menemukan bahwa prinsip-prinsip desain berorientasi objek dan sebagian besar pola tidak berubah sejak saat itu. Kami ingin mengubah kategorisasi, menambah beberapa anggota baru dan juga menghapus beberapa pola. Sebagian besar diskusi adalah tentang mengubah kategorisasi dan khususnya pola mana yang harus dibuang.

Ketika mendiskusikan pola mana yang harus dibuang, kami menemukan bahwa kami masih mencintai semuanya. (Tidak juga — saya mendukung menjatuhkan Singleton. Penggunaannya hampir selalu berbau desain.)

Jadi inilah beberapa perubahannya:

Interpreter dan Flyweight harus dipindahkan ke kategori terpisah yang kami sebut sebagai "Lainnya / Kompon" karena mereka benar-benar binatang buas yang berbeda dari pola lainnya. Metode Pabrik akan digeneralisasi ke Pabrik.

Kategori-kategori tersebut adalah: Inti, Penciptaan, Periferal, dan Lainnya. Maksudnya di sini adalah untuk menekankan pola-pola penting dan untuk memisahkannya dari pola-pola yang jarang digunakan.

Anggota baru adalah: Null Object, Type Object, Dependency Injection, dan Extension Object / Interface (lihat "Extension Object" dalam Bahasa Pola Desain Program 3, Addison-Wesley, 1997).

Ini adalah kategorinya:

Inti: Komposit, Strategi, Negara, Komando, Iterator, Proxy, Metode Templat, Fasad

Penciptaan: Pabrik, Prototipe, Pembangun, Injeksi Ketergantungan

Periferal: Pabrik Abstrak, Pengunjung, Dekorator, Mediator, Objek Jenis, Objek Null, Objek Ekstensi

Lainnya: Kelas Terbang, Penerjemah

— akuhn
sumber

Mengapa Anda menurunkan saya? Tolong jelaskan dalam komentar sehingga saya dapat meningkatkan jawabannya.

— akuhn

3

Pola aktual dalam buku ini kadang-kadang sangat berguna, tetapi mereka benar-benar hanya contoh dari alat yang lebih kuat yang diberikan buku ini kepada Anda: pemahaman yang mendalam tentang kapan dan di mana lebih baik untuk memotong kode monolitik di bagian independen yang dipisahkan dan diatur oleh sebuah antarmuka .

Ketika Anda mempelajari keterampilan itu, Anda menyadari bahwa Anda tidak perlu mengingat detail yang tepat dari setiap pola tunggal, karena Anda selalu dapat memotong solusi yang Anda terapkan dengan cara yang paling sesuai dengan tujuannya. Jadi ide untuk menulis lebih banyak dan lebih banyak pola tampaknya sangat akademis dan tidak berguna.

— lud1977
sumber

Poin yang bagus, namun saya ragu bahwa banyak orang memahami buku (atau pola pada umumnya) seperti itu.

— Frank Puffer

@ lud1977 jika kita tidak merekam sejarah, apa yang mencegah masa depan jatuh ke dalam perangkap yang sama? dengan demikian, itu harus selalu dicatat. itu tidak ada gunanya.

— r3wt

2

Jadi saya berharap jumlah pola desain yang dikenal dan didokumentasikan akan tumbuh secara signifikan.

Itu tidak terjadi. Lebih dari 20 tahun setelah buku GoF keluar, hanya 12 pola tambahan yang tercantum dalam artikel Wikipedia, yang sebagian besar jauh kurang populer daripada yang asli. (Saya tidak memasukkan pola konkurensi di sini karena mereka membahas topik tertentu.)

Buku GoF dan Wikipedia bukan satu-satunya sumber pola desain yang diketahui. Jika Anda hanya mencari "pola desain" di Amazon.com, Anda mendapatkan ratusan buku (coba pencarian ini ). Saya kira mereka hanya mencantumkan pola yang paling terkenal di artikel Wikipedia .

Jadi masalahnya bukan tidak ada cukup pola desain yang terdokumentasi. Sebaliknya ada begitu banyak sehingga tidak ada yang bisa menghafal semuanya dan kebanyakan programmer hanya mengenal sedikit. Janji besar bahasa pola umum rusak pada saat ini.

— iluwatar
sumber

-1

Mungkin ada banyak struktur yang belum dipikirkan. Selama orang mengembangkan perangkat lunak, akan ada tantangan desain untuk diatasi. Beberapa di antaranya mungkin dapat diselesaikan dengan menggunakan pola baru yang cerdas yang dapat digunakan orang lain.

Bahasa pemrograman telah berkembang dan berkembang untuk menghilangkan pola yang paling umum digunakan. Pola-pola itu masih ada dalam desain bahasa. Jadi mereka mungkin diabaikan hari ini, tetapi itu tidak membuat mereka tidak penting.

Apakah pengetahuan tentang cara membangun rumah tiba-tiba tidak penting begitu kita memiliki robot yang dapat melakukannya untuk kita? Saya berpendapat tidak, tidak. Ini kurang relevan, pasti - dan mungkin jauh lebih sedikit bermanfaat untuk dipelajari, karena permintaannya turun tajam, dan tidak ada orang lain yang mempelajarinya.

Jadi tidak, saya tidak percaya ruang pola seperti yang Anda sebut telah habis. Seperti yang ditunjukkan oleh jawaban lain, itu kemungkinan tidak terbatas. Tetapi ketika permintaan untuk desain sistem mereda, karena kami meningkatkan ketinggian menara abstraksi kami dan kekuatan bahasa pemrograman kami - semakin sedikit orang yang membangun di tingkat atas akan memperhatikan detail bagaimana menara itu dibangun .

— Tim
sumber

-2

Pola tidak terbatas .. Anda dapat men-tweak setiap pola atau mencocokkan dan mencocokkan untuk membuat yang baru .. Pola integrasi perusahaan juga didefinisikan dengan baik..jadi ya memang memakan waktu mendokumentasikan pola menggunakan uml dan menciptakan standar untuk menjelaskannya .. Tapi untuk setiap pola domain berkembang dan mereka juga berubah untuk bahasa ekspresif seperti python atau scala ..

— Marut Singh
sumber