Apakah ada pola desain yang tidak perlu dalam bahasa dinamis seperti Python?


98

Saya sudah mulai membaca buku pola desain oleh GoF. Beberapa pola tampak sangat mirip dengan hanya sedikit perbedaan konseptual.

Apakah Anda berpikir dari banyak pola yang beberapa tidak perlu dalam bahasa yang dinamis seperti Python (misalnya karena mereka diganti dengan fitur dinamis)?


1
Semacam pertanyaan yang menarik, karena itu menyiratkan bahwa pilihan bahasa dapat secara efektif menggantikan konstruksi kode.
joshin4colours

3
Bukan jawaban, tetapi relevan - Saya pikir pola desain GoF sama relevan untuk beberapa prinsip umum yang dapat disuling dari mereka seperti halnya untuk pola tertentu. Maksud saya bukan ide pola (meskipun itu jelas signifikan), tetapi lebih pada izin untuk menggunakan kelas dengan cara tertentu yang melanggar prinsip OOP naif. Misalnya, ada banyak pola di mana "bentuk" cukup jelas tidak "menggambar sendiri", atau setidaknya mendelegasikan beberapa aspek pekerjaan ke beberapa objek lain. Saya pikir pelajaran itu penting dalam bahasa apa pun yang mendukung OOP.
Steve314

Pertanyaan yang sangat menarik. Saya berharap saya bisa +5 bukannya +1.
MathAttack

1
Sekilas juga di Pola Desain Fitur Bahasa Hilang dan Pola Desain Fitur Bahasa Hilang di c2. Ini bahkan bukan masalah 'bahasa dinamis'. Contoh paling sederhana adalah pola iterator yang sepele dalam python, perl (dan bahkan Java - tidak dinamis).

Jawaban:


92

Peter Norvig menunjukkan bahwa 16 dari 23 pola desain yang ditemukan dalam buku GOF tidak terlihat atau lebih sederhana dalam bahasa dinamis (ia berfokus pada Lisp dan Dylan).

Karena Anda menyebutkan Python, ada presentasi yang bagus dari Alex Martelli tentang topik tersebut. Juga terkait dengan Python, ada posting blog yang bagus yang menunjukkan enam pola desain dalam Python idiomatik .

Saya juga menyimpan repositori github dengan implementasi (oleh orang lain) dari pola desain yang paling umum di Python .


Bagus! Itu akan menjadi titik pada jawaban :) Saya berharap semua orang telah memahami pertanyaan itu dengan jelas.
Gerenuk

2
Menurut Norvig, 2 dari 16 (Interpreter dan Iterator) "tidak terlihat atau lebih sederhana" karena makro (yang tidak dimiliki Python).
mjs

1
itu tidak jelas bagi saya bahwa semua pola ini tidak perlu karena lisp dinamis tetapi karena fitur lain seperti menjadi bahasa fungsional yang kuat
jk.

@ mjs Iterators adalah fitur bawaan dari Python.
sakisk

1
Jawaban yang bagus ini dapat bahkan sedikit ditingkatkan dengan mengubah keterangan link yang agak bermakna menunjukkan , presentasi dan repositori - mereka jauh lebih baik maka di sini , tapi, kau tahu ... :-)
Serigala

59

Tidak diperlukan pola desain. Dalam bahasa apa pun.

Saya cenderung menemukan banyak kode yang ditulis oleh orang-orang yang membaca tentang pola desain dan kemudian berpikir mereka harus menggunakannya di semua tempat. Hasilnya adalah bahwa kode aktual terkubur di bawah banyak antarmuka, pembungkus dan lapisan dan cukup sulit dibaca. Itu pendekatan yang salah untuk pola desain.

Pola desain ada sehingga Anda memiliki repertoar idiom berguna berguna ketika Anda menemukan masalah. Tetapi Anda tidak boleh menerapkan pola apa pun sebelum Anda mengidentifikasi masalah. Keep It Simple Bodoh harus selalu menjadi prinsip pemerintahan yang unggul.

Ini juga membantu untuk memikirkan pola desain sebagai konsep untuk memikirkan masalah daripada menulis kode boilerplate tertentu. Dan hampir semua boilerplate sebagai solusi untuk Java yang tidak memiliki fungsi bebas dan objek fungsi standar yang Anda gunakan di sebagian besar bahasa lain yang memilikinya (seperti Python, C #, C ++ dll).

Saya mungkin mengatakan bahwa saya memiliki pola pengunjung, tetapi dalam bahasa apa pun dengan fungsi kelas satu itu hanya akan menjadi fungsi yang mengambil fungsi. Alih-alih kelas pabrik saya biasanya hanya memiliki fungsi pabrik. Saya mungkin mengatakan saya memiliki antarmuka, tetapi kemudian itu hanya beberapa metode yang ditandai dengan komentar, karena tidak akan ada implementasi lain (tentu saja dengan python antarmuka selalu hanya komentar, karena itu bebek-ketik). Saya masih berbicara tentang kode sebagai menggunakan pola, karena ini adalah cara yang berguna untuk memikirkannya, tetapi tidak benar-benar mengetik semua barang sampai saya benar-benar membutuhkannya.

Jadi pelajari semua pola sebagai konsep . Dan lupakan implementasi spesifik. Implementasinya bervariasi, dan harus bervariasi, di dunia nyata, bahkan hanya di Jawa.


28
Pernyataan pembukaan Anda terlalu menyederhanakan ke ekstrim. Memang benar bahwa pola memiliki biayanya, jadi tidak boleh digunakan secara membabi buta, hanya demi itu. Tetapi di tempat yang tepat, mereka bisa sangat membantu. Dan ya, mereka spesifik bahasa - beberapa pola tidak perlu dalam beberapa bahasa karena bahasa itu sendiri mendukung pendekatan yang lebih baik. Tapi itu masih cukup jauh dari klaim pembukaan Anda.
Péter Török

2
Pengunjung Btw tidak sepenuhnya digantikan oleh fungsi urutan yang lebih tinggi - ini adalah solusi untuk menerapkan pengiriman ganda dalam bahasa yang tidak mendukungnya secara native (seperti C # dan C ++). (Dan memang harus digunakan dengan sangat hemat - Saya menganggapnya sebagai salah satu pola yang paling misterius dan mahal yang penggunaannya IMHO sangat sulit untuk dibenarkan bahwa saya sendiri belum pernah menggunakannya hingga sekarang.)
Péter Török

14
Ya, Anda tidak perlu pola. Yang Anda butuhkan adalah menyelesaikan masalah . Jika Anda tidak tahu pola apa pun untuknya, Anda masih bisa menyelesaikannya, itu akan membutuhkan lebih banyak pemikiran dan Anda mungkin akan menemukan solusi yang cocok dengan beberapa pola atau yang tidak. Mengetahui polanya justru membuatnya lebih mudah.
Jan Hudec

3
@Gerenuk: Ya, tapi intinya, bahwa polanya tidak spesifik bahasa, itu untuk kepala Anda. Anda sering menemukan bahwa beberapa pola direalisasikan jauh lebih mudah dan menggunakan alat yang berbeda dengan python, tetapi konsep yang sama biasanya ada.
Jan Hudec

4
@ PéterTörök: Pengunjung tidak digantikan oleh apa pun. Intinya konsep yang sama mungkin diimplementasikan menggunakan alat yang berbeda dalam kasus yang berbeda, tetapi saya masih menganggapnya sebagai pola yang sama.
Jan Hudec

13

Pola abstrak pabrik tidak perlu dalam bahasa yang diketik bebek seperti Python, karena praktis dibangun ke dalam bahasa.


10
yah, kamu masih butuh pabrik yang berbeda. Anda tidak perlu definisi antarmuka.
Stefano Borini

1
Jika Anda memiliki kelas, Anda sudah memiliki pabrik. Kelas adalah objek kelas satu dan dapat diedarkan di mana-mana dan hanya dipanggil untuk membuat objek (tidak seperti Java). Anda tidak perlu membuat yang lain. Jika Anda menginginkan sesuatu yang bukan konstruktor default, cukup buat lambda / callable dari beberapa jenis yang membungkus konstruktor dengan beberapa cara.
spookylukey

13

Satu-satunya yang terlintas dalam pikiran adalah pola Singleton.

Karena Python tidak memaksa Anda untuk menggunakan kelas untuk semuanya , Anda bisa menggunakan struktur data global saja. Struktur data global itu dapat dikelola oleh sebuah instance, tetapi Anda tidak harus mengontrol instantiation dari kelas itu, Anda cukup membuat instance pada impor dan membiarkannya begitu saja.

Sebagian besar, Singletons di python diganti dengan modul. Modul dalam python pada dasarnya adalah Lajang; interpreter python membuat ini hanya sekali dan sekali saja.

Semua pola lain di Patters Desain Saya telah menggunakan Python pada satu waktu atau yang lain, dan Anda akan menemukan contoh dari mereka di seluruh perpustakaan standar Python dan di Python itu sendiri.


2
Bukankah itu sebenarnya anti-pola akhir-akhir ini?
Den

16
Singleton adalah antipattern . Dalam semua bahasa. Itu dibuat untuk memecahkan beberapa masalah yang tidak berhubungan dan tidak cocok untuk keduanya (perhatikan, bahwa bahkan Java memiliki anggota statis, yang ada satu kali per kelas, jadi Anda tidak perlu contoh untuk itu).
Jan Hudec

1
Dan dengan Python kami tidak pernah repot dengan itu karena tidak pernah ada masalah untuk dipecahkan.
Martijn Pieters

1
"Python tidak memaksamu untuk menggunakan objek untuk semuanya" Tidak benar. Hanya saja tidak menjengkelkan seperti di Jawa, tapi tetap saja, dalam Python semuanya adalah objek. Modul genap adalah objek.
vartec

3
@ Darthfett: Saya sangat sadar bagaimana cara lenkerjanya; Guido membuat pilihan eksplisit di sini . Maksud saya adalah untuk menunjukkan bahwa Python bukan bahasa OOP murni; itu adalah bahasa pragmatis. Saya suka seperti itu.
Martijn Pieters

8

Pola desain adalah untuk programmer, bukan untuk bahasa. Programmer cenderung menggunakan pola yang membantu mereka memahami masalah yang dihadapi. Tidak ada pola desain yang benar-benar diperlukan, tetapi mungkin berguna untuk membantu menyederhanakan apa yang Anda coba lakukan.

Python, dan pengetikan bebek secara spesifik, memang memberikan akhir di sekitar banyak pola dan praktik umum, dan banyak pembatasan yang diberlakukan oleh beberapa pola (privasi, kekekalan, dll.) Hanya berlaku sejauh programmer setuju untuk tidak melanggarnya. . Tapi tetap, mereka tidak bekerja selama programmer bermain bersama. Sebuah pintu masih merupakan sebuah pintu, bahkan jika itu dibingkai oleh dinding imajiner.

Python dianggap sebagai bahasa "multi-paradigma"; Anda dapat menggunakan pola apa pun yang Anda inginkan. Ini disengaja. Ini menyediakan hirarki kelas yang kompleks, misalnya, meskipun sama sekali tidak perlu dan sedikit buatan. Tetapi bagi sebagian orang abstraksi tertentu itu bermanfaat. Bukan karena masalah menuntutnya, tetapi karena programmer melakukannya. Jadi begitulah.


Itu tentu menarik. Jadi pola mana yang Anda maksudkan yang mungkin dilupakan orang, karena ada cara yang lebih baik dalam Python?
Gerenuk

4

Buku "Pola Desain" yang asli mendokumentasikan dan menamai beberapa idiom umum yang berguna dalam bahasa-bahasa imperatif, berorientasi objek seperti C ++ dan Smalltalk. Tapi Smalltalk adalah bahasa yang diketik secara dinamis, jadi tidak bisa sepenuhnya menjadi dinamis.

Namun, jawaban untuk pertanyaan Anda masih "ya": beberapa pola desain ini tidak akan relevan dengan bahasa modern yang diketik secara dinamis. Lebih umum, akan ada yang berbeda pola desain dalam berbagai bahasa, terutama dalam berbagai macam bahasa.

Untuk mengulangi: "pola desain" hanyalah nama untuk idiom pemrograman: solusi umum untuk masalah yang sering ditemui. Bahasa yang berbeda membutuhkan idiom yang berbeda, karena apa masalah untuk satu bahasa mungkin sepele untuk yang lain. Dalam hal ini, pola desain cenderung menunjukkan kelemahan dalam bahasa yang mereka terapkan.

Jadi, Anda mungkin mencari fitur lain yang membuat bahasa dinamis modern (atau yang kuno seperti Lisp) lebih kuat, menjadikan beberapa pola desain klasik ini tidak relevan.


1

Pola desain adalah cara untuk menyelesaikan masalah tertentu. Jika masalah tidak terpenuhi, pola penyelesaiannya tidak ada gunanya.

Orang-orang berusaha untuk menyesuaikan pola desain di mana-mana seolah-olah itu adalah praktik terbaik untuk memiliki pola desain di proyek Anda. Itu sebaliknya. Anda menemukan masalah yang bisa diselesaikan dengan pola pabrik? Keren. Beradaptasi itu. Jangan mencari kode Anda dan mencoba menemukan tempat yang tepat untuk mengimplementasikan singleton (atau pabrik, atau fasad, atau apa pun ...).

Mungkin Python memiliki pola desain sendiri yang tidak tersedia untuk orang-orang Java dan .NET (karena sifat bahasa ini)?


1

Saya akan mengatakan bahwa pola selalu tergantung pada bahasa. Pola python yang paling mirip dengan yang didefinisikan dalam GoF itu karena OOP Python, yang dikatakan OOP tidak seperti OOP (tidak ada dua bahasa yang mendefinisikan objek dan manipulasi mereka 100% sama).

Jadi tidak ada keraguan beberapa pola tidak akan berlaku "sebagaimana adanya", beberapa mungkin tidak masuk akal dan ada beberapa pola yang mungkin hanya bermakna bagi Python.

Untuk membalas pertanyaan Anda dengan tepat: Pola hanya diperlukan jika Anda membutuhkannya . Anda tidak harus menggunakannya jika tidak diperlukan (seperti yang dikatakan Jan Hudec).

Selain itu, ada lebih banyak pola daripada yang disebutkan di GoF. Lihat di wikipedia pola lainnya

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.