Apakah pemrograman fungsional menggantikan pola desain GoF?


1047

Sejak saya mulai belajar F # dan OCaml tahun lalu, saya telah membaca sejumlah besar artikel yang menegaskan bahwa pola desain (terutama di Jawa) adalah solusi untuk fitur yang hilang dalam bahasa imperatif. Satu artikel yang saya temukan membuat klaim yang cukup kuat :

Kebanyakan orang yang saya temui telah membaca buku Pola Desain oleh Gang of Four (GoF). Setiap programmer yang menghargai diri sendiri akan memberi tahu Anda bahwa buku itu agnostik bahasa dan polanya berlaku untuk rekayasa perangkat lunak secara umum, apa pun bahasa yang Anda gunakan. Ini klaim yang mulia. Sayangnya itu jauh dari kebenaran.

Bahasa fungsional sangat ekspresif. Dalam bahasa fungsional seseorang tidak memerlukan pola desain karena bahasa tersebut kemungkinan tingkat tinggi, Anda akhirnya pemrograman dalam konsep yang menghilangkan pola desain bersama-sama.

Fitur utama pemrograman fungsional (FP) meliputi fungsi sebagai nilai kelas satu, currying, nilai yang tidak dapat diubah, dll. Tampaknya tidak jelas bagi saya bahwa pola desain OO mendekati salah satu dari fitur tersebut.

Selain itu, dalam bahasa fungsional yang mendukung OOP (seperti F # dan OCaml), tampak jelas bagi saya bahwa programmer yang menggunakan bahasa ini akan menggunakan pola desain yang sama yang ditemukan tersedia untuk setiap bahasa OOP lainnya. Bahkan, sekarang saya menggunakan F # dan OCaml setiap hari, dan tidak ada perbedaan mencolok antara pola yang saya gunakan dalam bahasa ini vs. pola yang saya gunakan saat saya menulis di Jawa.

Apakah ada kebenaran pada klaim bahwa pemrograman fungsional menghilangkan kebutuhan akan pola desain OOP? Jika demikian, dapatkah Anda memposting atau menautkan ke contoh pola desain OOP khas dan fungsional yang setara?


18
Anda mungkin melihat artikel oleh Steve Yegge ( steve-yegge.blogspot.com/2006/03/… )
Ralph

27
"buku ini agnostik bahasa dan pola-pola berlaku untuk rekayasa perangkat lunak secara umum" - perlu dicatat bahwa buku ini tidak setuju dengan klaim ini, dalam arti bahwa beberapa bahasa tidak perlu mengungkapkan hal-hal tertentu seperti pola desain: "Pola kami menganggap Smalltalk / C ++ - fitur bahasa level, dan pilihan itu menentukan apa yang bisa dan tidak dapat diimplementasikan dengan mudah [...] CLOS memiliki multi-metode, misalnya, yang mengurangi kebutuhan akan pola seperti Pengunjung (Halaman 331). " (halaman 4)
Guildenstern

6
Juga perlu diingat bahwa banyak pola desain bahkan tidak diperlukan dalam bahasa imperatif tingkat tinggi yang cukup.
R. Barzell

3
@ R.Barzell Apa itu "bahasa imperatif tingkat cukup tinggi"? Terima kasih.
cibercitizen1

5
@ cibercitizen1 bahasa yang diketik bebek dengan dukungan untuk fungsi tingkat tinggi dan fungsi anonim. Fitur-fitur ini memasok banyak daya yang disediakan oleh banyak pola desain.
R. Barzell

Jawaban:


1077

Posting blog yang Anda kutip melebih-lebihkan klaimnya. FP tidak menghilangkan kebutuhan akan pola desain. Istilah "pola desain" tidak banyak digunakan untuk menggambarkan hal yang sama dalam bahasa FP. Tetapi mereka ada. Bahasa fungsional memiliki banyak aturan praktik terbaik dari bentuk "ketika Anda menemukan masalah X, gunakan kode yang terlihat seperti Y", yang pada dasarnya adalah pola desain.

Namun, memang benar bahwa sebagian besar pola desain spesifik OOP cukup tidak relevan dalam bahasa fungsional.

Saya tidak berpikir itu harus sangat kontroversial untuk mengatakan bahwa pola desain secara umum hanya ada untuk memperbaiki kekurangan dalam bahasa. Dan jika bahasa lain dapat menyelesaikan masalah yang sama sepele, bahasa lain itu tidak membutuhkan pola desain untuk itu. Pengguna bahasa itu mungkin bahkan tidak menyadari bahwa masalahnya ada , karena, yah, itu bukan masalah dalam bahasa itu.

Inilah yang dikatakan Gang of Four tentang masalah ini:

Pilihan bahasa pemrograman 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. Jika kita mengasumsikan bahasa prosedural, kita mungkin telah memasukkan pola desain yang disebut "Warisan", "Enkapsulasi," dan "Polimorfisme". Demikian pula, beberapa pola kami didukung langsung oleh bahasa berorientasi objek yang kurang umum. CLOS memiliki multi-metode, misalnya, yang mengurangi kebutuhan akan pola seperti Pengunjung. Faktanya, ada cukup banyak perbedaan antara Smalltalk dan C ++ yang berarti bahwa beberapa pola dapat diekspresikan lebih mudah dalam satu bahasa daripada yang lain. (Lihat Iterator misalnya.)

(Di atas adalah kutipan dari buku Pengantar Pola Desain, halaman 4, paragraf 3)

Fitur utama pemrograman fungsional mencakup fungsi sebagai nilai kelas satu, currying, nilai yang tidak dapat diubah, dll. Tampaknya tidak jelas bagi saya bahwa pola desain OO mendekati salah satu dari fitur tersebut.

Apa pola perintah, jika bukan perkiraan fungsi kelas satu? :) Dalam bahasa FP, Anda cukup mengoper fungsi sebagai argumen ke fungsi lain. Dalam bahasa OOP, Anda harus membungkus fungsi dalam kelas, yang bisa Anda instantiate dan kemudian meneruskan objek itu ke fungsi lainnya. Efeknya sama, tetapi dalam OOP itu disebut pola desain, dan dibutuhkan lebih banyak kode. Dan apa pola pabrik abstrak, jika tidak kari? Lewati parameter ke fungsi sedikit demi sedikit, untuk mengonfigurasi nilai seperti apa yang dikeluarkan ketika Anda akhirnya memanggilnya.

Jadi ya, beberapa pola desain GoF dianggap berlebihan dalam bahasa FP, karena ada alternatif yang lebih kuat dan lebih mudah digunakan.

Tapi tentu saja masih ada pola desain yang tidak diselesaikan oleh bahasa FP. Berapakah FP setara dengan singleton? (Mengabaikan sejenak bahwa lajang umumnya merupakan pola yang mengerikan untuk digunakan.)

Dan itu bekerja dua arah juga. Seperti yang saya katakan, FP juga memiliki pola desainnya; orang biasanya tidak menganggapnya demikian.

Tapi Anda mungkin telah berlari melintasi monad. Apa yang mereka, jika bukan pola desain untuk "berurusan dengan negara global"? Itu masalah yang sangat sederhana dalam bahasa OOP sehingga tidak ada pola desain yang setara di sana.

Kami tidak memerlukan pola desain untuk "increment a static variable", atau "read from socket itu", karena hanya itu yang Anda lakukan .

Mengatakan monad adalah pola desain sama absurdnya dengan mengatakan Integer dengan operasi mereka yang biasa dan elemen nol adalah pola desain. Tidak, monad adalah pola matematika , bukan pola desain.

Dalam bahasa fungsional (murni), efek samping dan keadaan tidak dapat diubah tidak mungkin, kecuali jika Anda mengatasinya dengan "pola desain" monad, atau metode lainnya untuk memungkinkan hal yang sama.

Selain itu, dalam bahasa fungsional yang mendukung OOP (seperti F # dan OCaml), tampak jelas bagi saya bahwa programmer yang menggunakan bahasa ini akan menggunakan pola desain yang sama yang ditemukan tersedia untuk setiap bahasa OOP lainnya. Bahkan, sekarang saya menggunakan F # dan OCaml setiap hari, dan tidak ada perbedaan mencolok antara pola yang saya gunakan dalam bahasa ini vs pola yang saya gunakan saat saya menulis di Jawa.

Mungkin karena Anda masih berpikir secara imperatif? Banyak orang, setelah berhadapan dengan bahasa imperatif sepanjang hidup mereka, mengalami kesulitan melepaskan kebiasaan itu ketika mereka mencoba bahasa fungsional. (Saya telah melihat beberapa upaya yang cukup lucu di F #, di mana setiap fungsi secara harfiah hanyalah serangkaian pernyataan 'let', pada dasarnya seolah-olah Anda mengambil program C, dan mengganti semua titik koma dengan 'let'. :))

Tetapi kemungkinan lain adalah Anda belum menyadari bahwa Anda sedang memecahkan masalah sepele yang membutuhkan pola desain dalam bahasa OOP.

Saat Anda menggunakan currying, atau meneruskan fungsi sebagai argumen ke yang lain, berhenti dan pikirkan bagaimana Anda akan melakukannya dalam bahasa OOP.

Apakah ada kebenaran pada klaim bahwa pemrograman fungsional menghilangkan kebutuhan akan pola desain OOP?

Ya. :) Ketika Anda bekerja dalam bahasa FP, Anda tidak lagi membutuhkan pola desain khusus OOP. Tetapi Anda masih memerlukan beberapa pola desain umum, seperti MVC atau hal-hal spesifik non-OOP lainnya, dan Anda membutuhkan beberapa "pola desain" khusus FP. Semua bahasa memiliki kekurangan masing-masing, dan pola desain biasanya adalah bagaimana kita mengatasinya.

Bagaimanapun, Anda mungkin tertarik untuk mencoba bahasa FP "lebih bersih", seperti ML (favorit pribadi saya, setidaknya untuk tujuan pembelajaran), atau Haskell , di mana Anda tidak memiliki kruk OOP untuk digunakan kembali ketika Anda Sedang dihadapkan dengan sesuatu yang baru.


Seperti yang diharapkan, beberapa orang keberatan dengan definisi saya tentang pola desain sebagai "memperbaiki kekurangan dalam bahasa", jadi inilah alasan saya:

Seperti yang sudah dikatakan, sebagian besar pola desain khusus untuk satu paradigma pemrograman, atau kadang-kadang bahkan satu bahasa tertentu. Seringkali, mereka memecahkan masalah yang hanya ada dalam paradigma itu (lihat monad untuk FP, atau pabrik abstrak untuk OOP).

Mengapa tidak ada pola pabrik abstrak di FP? Karena masalah yang dicoba untuk dipecahkan tidak ada di sana.

Jadi, jika ada masalah dalam bahasa OOP, yang tidak ada dalam bahasa FP, maka jelas itu adalah kekurangan bahasa OOP. Masalahnya dapat dipecahkan, tetapi bahasa Anda tidak melakukannya, tetapi membutuhkan banyak kode boilerplate dari Anda untuk mengatasinya. Idealnya, kami ingin bahasa pemrograman kami secara ajaib membuat semua masalah hilang. Masalah apa pun yang masih ada pada prinsipnya adalah kekurangan bahasa. ;)


73
Pola desain menggambarkan solusi umum untuk masalah dasar. Tapi itu juga yang dilakukan bahasa dan platform pemrograman. Jadi Anda menggunakan pola desain ketika bahasa dan platform yang Anda gunakan tidak cukup.
yfeldblum

135
S.Lott: Mereka menggambarkan solusi untuk masalah yang ada dalam bahasa tertentu, ya. Tidak ada pola desain perintah dalam bahasa FP, karena masalah yang dicoba untuk dipecahkan tidak ada. Yang berarti mereka memecahkan masalah yang bahasa itu sendiri tidak dapat memecahkan. Artinya, kekurangan dalam bahasa
jalf

38
Monad adalah konsep matematika, dan Anda memperluasnya dengan klasifikasi Anda. Tentu, Anda dapat melihat fungsi, monoids, monads, matriks atau konsep matematika lainnya sebagai pola desain, tetapi lebih seperti algoritma dan struktur data ... konsep dasar, bahasa bebas.
Alexandru Nedelcu

41
Tentu, monad adalah konsep matematika, tetapi mereka juga sebuah pola. "Pola FP" dari monad agak berbeda dari konsep matematika monad. Yang pertama adalah pola yang digunakan untuk menyiasati "batasan" tertentu dalam bahasa FP murni. Yang terakhir adalah konsep matematika universal.
jalf

69
Perhatikan bahwa monad di Haskell digunakan untuk hal-hal lain selain dari keadaan yang bisa berubah, misalnya untuk pengecualian, kelanjutan, daftar pemahaman, penguraian, pemrograman asinkron dan sebagainya. Tetapi semua penerapan monad ini mungkin bisa disebut pola.
JacquesB

152

Apakah ada kebenaran pada klaim bahwa pemrograman fungsional menghilangkan kebutuhan akan pola desain OOP?

Pemrograman fungsional tidak sama dengan pemrograman berorientasi objek. Pola desain berorientasi objek tidak berlaku untuk pemrograman fungsional. Sebaliknya, Anda memiliki pola desain pemrograman fungsional.

Untuk pemrograman fungsional, Anda tidak akan membaca buku pola desain OO; Anda akan membaca buku-buku lain tentang pola desain FP.

agnostik bahasa

Tidak sepenuhnya. Hanya agnostik bahasa sehubungan dengan bahasa OO. Pola desain tidak berlaku untuk bahasa prosedural sama sekali. Mereka hampir tidak masuk akal dalam konteks desain basis data relasional. Mereka tidak berlaku saat mendesain spreadsheet.

pola desain OOP khas dan fungsional yang setara?

Seharusnya di atas tidak ada. Itu seperti meminta sepotong kode prosedural yang ditulis ulang sebagai kode OO. Ummm ... Jika saya menerjemahkan Fortran (atau C) asli ke Jawa, saya belum melakukan apa pun selain menerjemahkannya. Jika saya benar-benar menulis ulang menjadi paradigma OO, itu tidak akan lagi terlihat seperti Fortran atau C asli - itu tidak akan dapat dikenali.

Tidak ada pemetaan sederhana dari desain OO ke desain fungsional. Mereka cara yang sangat berbeda dalam memandang masalah.

Pemrograman fungsional (seperti semua gaya pemrograman) memiliki pola desain. Database relasional memiliki pola desain, OO memiliki pola desain, dan pemrograman prosedural memiliki pola desain. Semuanya memiliki pola desain, bahkan arsitektur bangunan.

Pola desain - sebagai sebuah konsep - adalah cara pembangunan abadi, terlepas dari teknologi atau domain masalah. Namun, pola desain spesifik berlaku untuk domain dan teknologi masalah tertentu.

Setiap orang yang berpikir tentang apa yang mereka lakukan akan mengungkap pola desain.


12
MVC bukan desain OO. Ini desain arsitektur - pola itu berlaku cukup luas.
S.Lott

1
@ Putri: pemrograman fungsional tidak selalu lebih sederhana. Dalam contoh Anda, ya. Untuk hal-hal lain, juri masih keluar. Tetapi Anda telah membuang pola desain Java OO dan mengadopsi pola desain FP.
S.Lott

1
+1: Saya lebih suka jawaban ini daripada jawaban Jalf di atas. Meskipun beberapa pola desain mengatasi kekurangan dalam bahasa, tidak semua melakukannya. Sebagai contoh, saya hampir tidak akan mengatakan bahwa pola desain "melepaskan ikatan rekursif" mengatasi kekurangan dalam bahasa, itu hanya ungkapan yang berguna untuk melonggarkan ketergantungan.
Jon Harrop

9
Java 8 akan menyertakan penutupan alias fungsi anonim alias ekspresi lambda. Ini akan membuat pola desain perintah menjadi usang untuk Java. Ini adalah contoh dari kekurangan bahasa, bukan? Mereka menambahkan fitur yang hilang dan sekarang Anda tidak perlu pola desain.
Todd Chaffee

2
+1 untuk kalimat penutup. Pola desain dimaksudkan untuk menyederhanakan pemrograman dan membuat program yang dihasilkan lebih efisien, pada apa yang seharusnya mereka lakukan.
Penyortir

46

Komentar Brian tentang hubungan erat antara bahasa dan pola adalah intinya,

Bagian yang hilang dari diskusi ini adalah konsep idiom. Buku James O. Coplien, "Advanced C ++" adalah pengaruh besar di sini. Jauh sebelum dia menemukan Christopher Alexander dan Kolom Tanpa Nama (dan Anda tidak dapat berbicara dengan bijaksana tentang pola tanpa membaca Alexander juga), ia berbicara tentang pentingnya menguasai idiom dalam benar-benar belajar bahasa. Dia menggunakan string copy dalam C sebagai contoh, while(*from++ = *to++);Anda dapat melihat ini sebagai bandaid untuk fitur bahasa yang hilang (atau fitur perpustakaan), tetapi yang benar-benar penting adalah bahwa itu adalah unit pemikiran yang lebih besar, atau ekspresi, daripada bagian-bagiannya.

Itulah yang coba dilakukan oleh pola, dan bahasa, untuk memungkinkan kami mengekspresikan niat kami secara lebih ringkas. Semakin kaya unit pemikiran, semakin kompleks pikiran yang dapat Anda ungkapkan. Memiliki kosakata yang kaya dan dibagikan pada berbagai skala - mulai dari arsitektur sistem hingga sedikit-banyak - memungkinkan kita untuk memiliki percakapan yang lebih cerdas, dan pemikiran tentang apa yang harus kita lakukan.

Kita juga dapat, sebagai individu, belajar. Yang merupakan inti dari latihan ini. Kita masing-masing dapat memahami dan menggunakan hal-hal yang kita tidak akan pernah bisa memikirkan diri kita sendiri. Bahasa, kerangka kerja, perpustakaan, pola, idiom, dan sebagainya semuanya memiliki tempat dalam berbagi kekayaan intelektual.


8
Terima kasih! ini adalah tentang pola apa - "chunking konseptual" untuk menurunkan beban kognitif.
Randall Schulz

Dan Fungsional Monads pasti termasuk dalam diskusi ini.
Greg

@ RandallSchulz: fitur bahasa (dan penggunaan idiomatik mereka, tentu saja) juga akan masuk dalam kategori "pemotongan konseptual untuk menurunkan beban kognitif."
Roy Tinker

39

Buku GoF secara eksplisit mengikat dirinya pada OOP - judulnya adalah Pola Desain - Elemen Perangkat Lunak Berorientasi Objek yang Dapat Digunakan Kembali (penekanan tambang).



26

Berikut tautan lain, membahas topik ini: http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Dalam posting blognya Edward menjelaskan semua 23 pola GoF asli dalam hal Haskell.


4
Artikel itu tampaknya tidak benar-benar menunjukkan pola desain di Haskell, tetapi menunjukkan bagaimana Haskell mengatasi kebutuhan itu tanpa pola tersebut.
Fresheyeball

3
@Fresheyball: Tergantung pada definisi pola Anda. Apakah pemetaan fungsi pada daftar merupakan varian dari pola Pengunjung? Saya biasanya berpikir jawabannya adalah "ya." Pola seharusnya melampaui sintaksis tertentu. Fungsi yang diterapkan bisa dibungkus sebagai objek atau dilewatkan sebagai penunjuk fungsi, tetapi konsepnya sama, bagi saya. Apakah Anda tidak setuju?
srm

20

Ketika Anda mencoba untuk melihat ini pada tingkat "pola desain" (secara umum) dan "FP versus OOP", jawaban yang Anda akan temukan akan menjadi suram.

Pergi tingkat yang lebih dalam pada kedua sumbu, meskipun, dan mempertimbangkan pola desain khusus dan fitur bahasa tertentu dan hal-hal menjadi lebih jelas.

Jadi, misalnya, beberapa pola tertentu, seperti Pengunjung , Strategi , Perintah , dan Pengamat jelas berubah atau menghilang saat menggunakan bahasa dengan jenis data aljabar dan pencocokan pola , penutupan , fungsi kelas satu , dll. Beberapa pola lain dari buku GoF masih 'tetaplah', meskipun.

Secara umum, saya akan mengatakan bahwa, seiring waktu, pola-pola tertentu dihilangkan oleh fitur-fitur bahasa baru (atau semakin populer). Ini adalah kursus alami desain bahasa; karena bahasa menjadi lebih tingkat tinggi, abstraksi yang sebelumnya hanya bisa dipanggil dalam buku menggunakan contoh sekarang menjadi aplikasi fitur bahasa atau perpustakaan tertentu.

(Selain: inilah blog terbaru yang saya tulis, yang memiliki tautan lain ke diskusi lebih lanjut tentang pola desain dan KB.)


Bagaimana Anda bisa mengatakan bahwa pola pengunjung "menghilang"? Bukankah itu hanya berubah dari "membuat antarmuka Pengunjung dengan banyak metode Kunjungi" menjadi "menggunakan jenis penyatuan dan pencocokan pola"?
Gabe

22
Ya, tetapi itu berubah dari pola yang merupakan ide desain yang Anda baca dalam sebuah buku dan berlaku untuk kode Anda, menjadi "kode adil". Yaitu, "gunakan jenis gabungan dan pencocokan pola" adalah cara Anda biasanya mengode hal-hal dalam bahasa seperti itu. (Analogi: jika tidak ada bahasa memiliki forloop dan mereka semua hanya memiliki whileloop, maka "Untuk" mungkin merupakan pola iterasi. Tetapi ketika forhanya sebuah konstruksi yang didukung oleh bahasa dan bagaimana orang-orang kode secara normal, maka itu bukan pola - Anda tidak "Aku butuh pola, hanya kode, man."
Brian

4
Dengan kata lain, tes lakmus mungkin-tidak-buruk untuk "apakah itu sebuah pola" adalah: kode sekarang ditulis dengan cara ini untuk mahasiswa sarjana tahun kedua jurusan CS dengan satu tahun pengalaman pemrograman dalam bahasa Anda. Jika Anda menunjukkan kode, dan mereka pergi "itu desain yang pintar", maka itu adalah pola. Jika Anda menunjukkan kepada mereka kode, dan mereka pergi "baik, ya!", Maka itu bukan pola. (Dan jika Anda menunjukkan "Pengunjung" ini kepada siapa pun yang telah melakukan ML / F # / Haskell selama satu tahun, mereka akan berkata "baik, ya!")
Brian

1
Brian: Saya pikir kita hanya memiliki definisi "pola" yang berbeda. Saya menganggap abstraksi desain yang dapat diidentifikasi sebagai pola , sementara Anda hanya menganggap abstraksi yang tidak jelas sebagai sebuah pola . Hanya karena C # telah foreachdan Haskell mapMtidak berarti mereka tidak memiliki pola Iterator. Saya tidak melihat masalah dalam mengatakan bahwa pola Iterator diimplementasikan sebagai antarmuka generik IEnumerable<T>di C # dan typeclass Traversabledi Haskell.
Gabe

Mungkin pola yang tidak jelas berguna untuk insinyur perangkat lunak tetapi semua pola digunakan untuk perancang bahasa. Yaitu "Jika Anda membuat bahasa baru, pastikan untuk memasukkan cara yang bersih untuk mengekspresikan pola iterator." Bahkan pola yang jelas menarik ketika kita mulai mengajukan pertanyaan, "Apakah ada sintaksis yang lebih baik untuk mengekspresikan ide ini?" Bagaimanapun, itulah yang menuntun seseorang untuk membuat foreach.
srm

16

Presentasi Norvig menyinggung analisis yang mereka lakukan dari semua pola GoF, dan mereka mengatakan bahwa 16 dari 23 pola memiliki implementasi yang lebih sederhana dalam bahasa fungsional, atau hanya bagian dari bahasa. Jadi agaknya paling tidak tujuh dari mereka adalah a) sama rumitnya atau b) tidak hadir dalam bahasa tersebut. Sayangnya bagi kami, mereka tidak disebutkan!

Saya pikir sudah jelas bahwa sebagian besar pola "kreatif" atau "struktural" di GoF hanyalah trik untuk mendapatkan sistem tipe primitif di Jawa atau C ++ untuk melakukan apa yang Anda inginkan. Tetapi sisanya layak dipertimbangkan tidak peduli bahasa apa yang Anda gunakan.

Seseorang mungkin Prototipe; sementara itu adalah gagasan mendasar tentang JavaScript, itu harus diimplementasikan dari awal dalam bahasa lain.

Salah satu pola favorit saya adalah pola Obyek Null: mewakili tidak adanya sesuatu sebagai objek yang tidak melakukan apa pun yang sesuai. Ini mungkin lebih mudah untuk dimodelkan dalam bahasa fungsional. Namun, pencapaian nyata adalah pergeseran perspektif.


2
Analisis yang aneh untuk dilakukan karena pola GoF dirancang khusus untuk bahasa OOP berbasis kelas. Sepertinya sedikit seperti menganalisis apakah kunci pas pipa baik untuk melakukan pekerjaan listrik.
murah hati

@munificent: Tidak juga. Orientasi objek menyediakan polimorfisme; pemrograman fungsional umumnya menyediakan polimorfisme.
Marcin

@Marcin seorang programmer OO berarti sesuatu yang sangat berbeda oleh polimorfisme daripada programmer fungsional.
AndrewC

@AndrewC saya tidak setuju. Pemrogram OO mungkin berpikir itu berarti sesuatu yang berbeda, tetapi tidak.
Marcin

3
@Marcin Dalam pengalaman saya, seorang programmer OO biasanya mengacu pada polimorfisme subtipe (sering hanya menggunakan Object), memanfaatkan gips untuk mencapainya, atau polimorfisme ad-hoc (kelebihan beban dll). Ketika seorang programmer fungsional mengatakan polimorfisme yang mereka maksud adalah polimorfisme parametrik (yaitu bekerja untuk semua jenis data - Int, fungsi, daftar), yang mungkin lebih seperti pemrograman generik OO daripada seperti apa pun yang biasanya disebut oleh programmer OO polimorfisme.
AndrewC

15

Saya akan mengatakan bahwa ketika Anda memiliki bahasa seperti Lisp dengan dukungannya untuk makro, maka Anda dapat membangun Anda sendiri abstraksi khusus domain, abstraksi yang sering jauh lebih baik daripada solusi idiom umum.


Saya benar-benar tersesat. Untuk meningkatkan sesuatu dengan abstraksi ... Apa artinya itu?
tuinstoel

2
Anda dapat membuat abstraksi khusus domain (bahkan yang tertanam) tanpa makro. Macro hanya membiarkan Anda cantik dengan menambahkan sintaks khusus.
Jon Harrop

2
Anda dapat menganggap Lisp sebagai seperangkat Lego untuk membangun bahasa pemrograman - itu adalah bahasa tetapi juga bahasa logam. Yang berarti bahwa untuk domain masalah apa pun, Anda dapat merancang khusus bahasa yang tidak memiliki kekurangan yang jelas. Ini akan membutuhkan beberapa latihan, dan Kurt Gödel mungkin tidak setuju, tetapi perlu menghabiskan waktu bersama Lisp untuk melihat apa yang dibawa ke meja (petunjuk, makro).
Greg

9

Dan bahkan solusi pola desain OO adalah spesifik bahasa.

Pola desain adalah solusi untuk masalah umum yang tidak dipecahkan oleh bahasa pemrograman Anda untuk Anda. Di Jawa, pola Singleton memecahkan masalah satu-dari-sesuatu (disederhanakan).

Di Scala, Anda memiliki konstruk tingkat atas yang disebut Obyek selain Kelas. Ini malas dipakai dan hanya ada satu. Anda tidak harus menggunakan pola Singleton untuk mendapatkan Singleton. Itu bagian dari bahasa.


8

Pola adalah cara untuk menyelesaikan masalah serupa yang dapat dilihat berulang kali, dan kemudian dideskripsikan dan didokumentasikan. Jadi tidak, FP tidak akan menggantikan pola; namun, FP mungkin menciptakan pola baru, dan membuat beberapa pola "praktik terbaik" saat ini "usang".


4
Pola GoP adalah cara untuk menyelesaikan masalah keterbatasan jenis bahasa pemrograman tertentu yang menghalangi Anda. Misalnya "Saya ingin secara tidak langsung di kelas, dan minta mereka membuat objek" -> "Anda tidak bisa, tetapi Anda bisa membuat objek seperti metaclass yang disebut Factory". "Saya ingin banyak pengiriman" -> "Anda tidak bisa, tetapi ada labirin yang bisa Anda implementasikan disebut Pola Pengunjung". Dll. Tidak ada pola yang masuk akal jika Anda tidak menggunakan bahasa OOP dengan batasan tertentu.
Kaz

1
Saya tidak tahu tentang "tidak ada" dari mereka yang masuk akal dalam bahasa lain, tetapi saya akan setuju bahwa banyak dari mereka tidak masuk akal dalam bahasa lain. Adapter dan Bridge tampaknya memiliki lebih banyak kemungkinan multibahasa, sedikit berkurang untuk pengunjung, dan mungkin sedikit lebih sedikit untuk pendengar. Namun, pola lintas bahasa selalu akan menderita dari "bagaimana melakukan operasi bahasa X dalam bahasa Y" yang menopang batas-batas alami bahasa. Contoh sempurna adalah pola Singleton, yang pada dasarnya, bagaimana cara mendapatkan C global di OOP? (yang akan saya jawab, Anda seharusnya tidak).
Edwin Buck

1
Saya kedua Kaz: Pola bukan "cara memecahkan masalah serupa yang bisa dilihat lagi dan lagi" tetapi "cara memecahkan masalah serupa yang bisa dilihat lagi dan lagi DAN harus ditulis ulang lagi dan lagi karena bahasa tidak memungkinkan orang untuk tulis hanya sekali ". Dengan kata lain, jika bahasa memungkinkan pola untuk diekstraksi / diabstraksi di perpustakaan / kelas / modul dll itu berhenti menjadi pola tetapi menjadi perpustakaan / kelas / modul. Dalam FP, jauh lebih mudah untuk mengekstrak / mengabstraksi sedikit kode ke suatu fungsi, oleh karena itu "pola" lebih mudah dikonversi dalam kode yang dapat digunakan kembali menjadikannya bukan pola.
mb14

1
Penafsiran Anda disambut baik, tetapi buku GoF jelas untuk mendefinisikan suatu pola, dan jika Anda membaca bab-bab pengantar, buku itu tidak mengatakan apa-apa tentang bahasa, atau kelemahan bahasa. Tentu saja beberapa bahasa memiliki area yang akan membuat mereka meningkatkan beberapa pola lebih sering, tetapi apakah Anda menulisnya sepuluh kali (memotong dan menempel) atau menerapkannya sekali dengan sepuluh realisasi (sub-klasifikasi), atau memiliki kerangka kerja yang dikonfigurasi untuk melakukannya sepuluh sedikit cara yang berbeda, hanya merupakan detail implementasi dari pola yang diekspos.
Edwin Buck

1
Mengembara kembali ke percakapan ini setelah bertahun-tahun, saya pikir banyak orang mengaitkan Pola dengan bahasa pemrograman tertentu atau paradigma pemrograman tertentu. Mereka dapat digunakan dalam konteks seperti itu, tetapi mereka ada sebelum pemrograman. "Cara membangun abadi" membahas pola-pola dalam membangun arsitektur dan perencanaan masyarakat. Ini menyiratkan bahwa teknik-teknik yang berorientasi pola dapat digunakan di luar "keterbatasan bahasa" kecuali jika Anda ingin menyebut konstruksi bangunan sebagai bahasa pemrograman :)
Edwin Buck

8

Seperti yang orang lain katakan, ada pola khusus untuk pemrograman fungsional. Saya pikir masalah menghilangkan pola desain bukan hanya masalah beralih ke fungsional, tetapi masalah fitur bahasa .

Lihatlah bagaimana Scala menghilangkan "pola tunggal": Anda cukup mendeklarasikan objek, bukan kelas. Fitur lain, pencocokan pola, membantu menghindari kekakuan pola pengunjung. Lihat perbandingannya di sini: Pencocokan Pola Scala = Pola Pengunjung pada Steroid

Dan Scala, seperti F #, adalah perpaduan dari OO-fungsional. Saya tidak tahu tentang F #, tetapi mungkin memiliki fitur semacam ini.

Penutupan hadir dalam bahasa fungsional, tetapi tidak perlu dibatasi. Mereka membantu dengan pola delegator.

Satu lagi pengamatan. Sepotong kode ini mengimplementasikan sebuah pola: ini sangat klasik dan sangat elemental sehingga kita biasanya tidak menganggapnya sebagai "pola", tetapi jelas:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

Bahasa imperatif seperti Java dan C # telah mengadopsi apa yang pada dasarnya merupakan konstruksi fungsional untuk menangani hal ini: "foreach".


Saya akan mengatakan bahwa Scala termasuk dukungan kelas satu untuk pola tunggal. Polanya masih ada, tetapi kode boilerplate yang diperlukan untuk menerapkan pola sangat berkurang dibandingkan dengan Jawa.
JacquesB

Jika pendapat itu seperti *******, well ... Lihatlah sisa jawabannya. "Anda hanya mendeklarasikan objek bukan kelas" begitu benar, saya akan secara eksplisit menyebutnya objek literal (yaitu var singleton = {};). Saya juga suka menyebutkan tentang pola foreach. Sayangnya, sepertinya sebagian besar orang yang menjawab / mengomentari pertanyaan ini tidak memahami pemrograman fungsional dan lebih suka membenarkan penggunaan pola desain OOP. +1 untuk memberikan contoh nyata, saya akan memberikan lebih banyak jika saya bisa.
Evan Plaice

@ JacquesB Saya tidak dapat mengomentari Scala / Haskell tetapi dalam JavaScript (mis. Hybrid fungsional / imperatif) sama sekali tidak ada boilerplate Anda hanya menyesuaikan cara Anda mendeklarasikan objek dengan menggunakan kombinasi sintaks literal objek, fungsi anonim, fungsi lewat sebagai yang pertama anggota kelas, dan memungkinkan pewarisan berganda (menghilangkan kebutuhan untuk kontrak antarmuka).
Evan Plaice

8

Pola Desain GoF mengkode resep solusi untuk bahasa OO yang merupakan keturunan dari Simula 67 , seperti Java dan C ++.

Sebagian besar "penyakit" yang dirawat oleh pola desain disebabkan oleh:

  • kelas yang diketik secara statis, yang menentukan objek, tetapi bukan objek itu sendiri;
  • pembatasan untuk pengiriman tunggal (hanya argumen paling kiri yang digunakan untuk memilih metode, argumen yang tersisa dianggap sebagai tipe statis saja: jika mereka memiliki tipe dinamis, tergantung pada metode untuk mengatasinya dengan pendekatan ad-hoc);
  • perbedaan antara pemanggilan fungsi biasa dan pemanggilan fungsi berorientasi objek, yang berarti bahwa fungsi berorientasi objek tidak dapat dilewatkan sebagai argumen fungsional di mana fungsi reguler diharapkan dan sebaliknya; dan
  • perbedaan antara "tipe dasar" dan "tipe kelas".

Tidak ada satu pun dari pola desain ini yang tidak hilang di Common Lisp Object System, meskipun solusinya terstruktur pada dasarnya dengan cara yang sama seperti pada pola desain yang sesuai. (Selain itu, sistem objek mendahului buku GoF lebih dari satu dekade. Common Lisp menjadi standar ANSI pada tahun yang sama ketika buku itu pertama kali diterbitkan.)

Sejauh menyangkut pemrograman fungsional, apakah pola-pola berlaku atau tidak tergantung pada apakah bahasa pemrograman fungsional yang diberikan memiliki beberapa jenis sistem objek, dan apakah itu dimodelkan setelah sistem objek yang mendapat manfaat dari pola. Jenis objek-orientasi tidak tercampur dengan baik dengan pemrograman fungsional, karena mutasi keadaan ada di depan dan tengah.

Konstruksi dan akses non-mutasi kompatibel dengan pemrograman fungsional, sehingga pola yang berkaitan dengan akses atau konstruksi abstrak dapat diterapkan: pola seperti Pabrik, Fasad, Proksi, Dekorator, dan Pengunjung.

Di sisi lain, pola perilaku seperti Negara dan Strategi mungkin tidak secara langsung berlaku dalam OOP fungsional karena mutasi negara adalah inti mereka. Ini tidak berarti mereka tidak berlaku; mungkin mereka entah bagaimana berlaku dalam kombinasi dengan trik apa pun yang tersedia untuk mensimulasikan keadaan yang bisa berubah.


2
"Pola Desain GoF mengkode resep pemecahan masalah" hanyalah pernyataan yang salah.
John Peters

7

Saya ingin menyambungkan beberapa makalah yang sangat bagus tetapi agak padat oleh Jeremy Gibbons: "Desain pola sebagai program generik tipe data orde tinggi" dan "Inti dari pola Iterator" (keduanya tersedia di sini: http: // www. comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

Keduanya menggambarkan bagaimana konstruksi fungsional idiomatik menutupi medan yang dicakup oleh pola desain khusus di pengaturan (berorientasi objek) lainnya.


6

Anda tidak dapat melakukan diskusi ini tanpa memunculkan sistem tipe.

Fitur utama pemrograman fungsional mencakup fungsi sebagai nilai kelas satu, currying, nilai yang tidak dapat diubah, dll. Tampaknya tidak jelas bagi saya bahwa pola desain OO mendekati salah satu dari fitur tersebut.

Itu karena fitur-fitur ini tidak membahas masalah yang sama seperti yang dilakukan OOP ... mereka adalah alternatif untuk pemrograman imperatif. Jawaban FP untuk OOP terletak pada sistem tipe ML dan Haskell ... khusus jumlah tipe, tipe data abstrak, modul ML, dan kacamata jenis Haskell.

Tapi tentu saja masih ada pola desain yang tidak diselesaikan oleh bahasa FP. Berapakah FP setara dengan singleton? (Mengabaikan sejenak bahwa lajang umumnya merupakan pola yang mengerikan untuk digunakan)

Hal pertama yang dilakukan typeclasses adalah menghilangkan kebutuhan akan lajang.

Anda dapat membaca daftar 23 dan menghilangkan lebih banyak, tetapi saya tidak punya waktu untuk sekarang.


6
Bagaimana typeclasses (padanan FP dari antarmuka OOP) menghilangkan kebutuhan akan lajang (padanan FP dari negara global)?
Gabe

4

Saya pikir hanya dua Pola Desain GoF yang dirancang untuk memperkenalkan logika pemrograman fungsional ke dalam bahasa OO alami. Saya berpikir tentang Strategi dan Komando. Beberapa pola desain GoF lainnya dapat dimodifikasi oleh pemrograman fungsional untuk menyederhanakan desain dan menjaga tujuannya.


4
Masalahnya, poin utama banyak pola adalah untuk memanfaatkan polimorfisme untuk melakukan hal-hal yang memungkinkan dukungan yang layak untuk konsep KB secara otomatis. (Sebagian besar inkarnasi yang saya lihat dari Builder, misalnya, hanya setengah-setengah currying.) Setelah Anda dapat dengan mudah memperlakukan fungsi sebagai nilai, pola seringkali menyederhanakan ke titik sepele. Mereka menjadi "lulus panggilan balik" atau "memiliki kamus panggilan balik" - dan kelas pembangun yang berbeda, misalnya, semuanya bisa hilang. IMO suatu pola berhenti menjadi suatu pola setelah itu cukup sepele untuk menjadi seperti bagaimana segala sesuatunya bekerja , daripada sesuatu yang perlu Anda terapkan.
cHao


3

Pemrograman fungsional tidak menggantikan pola desain. Pola desain tidak bisa diganti.

Pola hanya ada; mereka muncul seiring waktu. Buku GoF memformalkan beberapa di antaranya. Jika pola-pola baru terungkap karena pengembang menggunakan bahasa pemrograman fungsional yang merupakan hal yang menarik, dan mungkin akan ada buku yang ditulis tentang mereka juga.


1
Pola desain tidak bisa diganti? Saya pikir itu agak tertutup. Kita semua mungkin sepakat bahwa pola desain dimaksudkan untuk menyelesaikan masalah pemrograman, dan setidaknya saya ingin berharap bahwa suatu hari kita bisa menyelesaikan masalah itu tanpa pola desain.
Metropolis

3
Setiap pola tertentu mungkin bisa diganti, tetapi konsep pola tidak bisa. Ingat bahwa istilah "pola" muncul di bidang arsitektur .
Frank Shearar

1
Pola tidak dimaksudkan untuk menyelesaikan masalah pemrograman. Pola adalah cara kita memprogram. Dokumentasi pola dimaksudkan untuk membantu memecahkan masalah pemrograman.
Torbjørn

3
@ Torbjørn: Pola adalah cara yang kami programkan saat bahasa menghalangi . Mereka ada karena beberapa ketidakcocokan antara perilaku yang diinginkan program dan kemampuan built-in bahasa, di mana persyaratan dan kemampuan tidak memetakan dengan baik atau memetakan secara ambigu. Jika bukan karena itu, tidak akan ada pola; Anda akan memiliki satu implementasi yang hanya bagaimana hal-hal dilakukan , dan implementasi lainnya secara efektif tidak layak dipertimbangkan.
cHao

1
Kecuali bahwa pola benar-benar ada hanya untuk memudahkan komunikasi. Tidak ada tujuan lain. Dan dalam semua pertemuan desain yang saya hadiri selama bertahun-tahun, diskusi tentang algoritma adalah apa yang penting, bukan polanya. Polanya jarang menjelaskan apa yang sebenarnya terjadi dalam arti yang berarti. Apakah ini menjelaskan secara tepat dampak O (n) vs O (n Log (n))? Tidak. Apakah ini menjelaskan betapa mudahnya cocok dengan arsitektur yang ada? Tidak. Diskusi algoritma skala penuh dilakukan. Saya tidak berargumen bahwa pola harus dihentikan per se, tetapi jika mereka, hampir tidak ada yang akan menderita sebagai hasilnya.

3

Dalam buku baru 2013 berjudul "Pola Pemrograman Fungsional- dalam Scala dan Clojure" penulis Michael.B. Linn melakukan pekerjaan yang layak membandingkan dan menyediakan penggantian dalam banyak kasus untuk pola GoF dan juga membahas pola fungsional yang lebih baru seperti 'rekursi ekor', 'memoisasi', 'urutan malas', dll.

Buku ini tersedia di Amazon. Saya menemukan itu sangat informatif dan menggembirakan ketika datang dari latar belakang OO beberapa dekade.


3

OOP dan pola GoF berurusan dengan negara. OOP memodelkan realitas untuk menjaga basis kode sedekat mungkin dengan persyaratan realitas yang diberikan. Pola desain GoF adalah pola yang diidentifikasi untuk memecahkan masalah dunia nyata atom. Mereka menangani masalah negara dengan cara semantik.

Seperti dalam pemrograman fungsional nyata tidak ada keadaan, tidak masuk akal untuk menerapkan pola GoF. Tidak ada pola desain fungsional dengan cara yang sama ada pola desain GoF. Setiap pola desain fungsional adalah buatan berbeda dengan kenyataan karena fungsi adalah konstruksi dari matematika dan bukan kenyataan.

Fungsi tidak memiliki konsep waktu karena mereka selalu mengembalikan nilai yang sama apa pun waktu saat ini kecuali waktu adalah bagian dari parameter fungsi yang membuatnya sangat sulit untuk memproses "permintaan di masa depan". Bahasa hibrid mencampurkan konsep-konsep tersebut membuat bahasa tidak menjadi bahasa pemrograman fungsional yang sebenarnya.

Bahasa fungsional meningkat hanya karena satu hal: pembatasan fisika saat ini. Prosesor hari ini terbatas dalam kecepatan pemrosesan instruksi karena hukum fisik. Anda melihat stagnasi dalam frekuensi clock tetapi ekspansi dalam core pemrosesan. Itu sebabnya paralelisme instruksi menjadi semakin penting untuk meningkatkan kecepatan aplikasi modern. Karena pemrograman fungsional menurut definisi tidak memiliki keadaan dan oleh karena itu tidak memiliki efek samping, aman untuk memproses fungsi secara paralel secara aman.

Pola GoF tidak usang. Mereka setidaknya diperlukan untuk memodelkan persyaratan dunia nyata. Tetapi jika Anda menggunakan bahasa pemrograman fungsional Anda harus mengubahnya menjadi padanan hibrid mereka. Akhirnya Anda tidak memiliki kesempatan untuk membuat hanya program fungsional jika Anda menggunakan ketekunan. Untuk elemen hibrida dari program Anda, masih ada keharusan untuk menggunakan pola GoF. Untuk elemen lain yang murni fungsional, tidak ada keharusan untuk menggunakan pola GoF karena tidak ada keadaan.

Karena pola GoF tidak diperlukan untuk pemrograman fungsional nyata, itu tidak berarti bahwa prinsip-prinsip SOLID tidak boleh diterapkan. Prinsip-prinsip SOLID berada di luar paradigma bahasa apa pun.


2
FP dapat memiliki status - tidak ada kondisi global, dibagi, atau bisa berubah.
vt5491

2

Dalam pemrograman fungsional, pola desain memiliki arti yang berbeda. Bahkan, sebagian besar pola desain OOP tidak perlu dalam pemrograman fungsional karena tingkat abstraksi yang lebih tinggi dan HOF digunakan sebagai blok bangunan.

Prinsip HOF berarti bahwa fungsi dapat diteruskan sebagai argumen ke fungsi lain. dan fungsi dapat mengembalikan nilai.


1

Seperti jawaban yang diterima mengatakan, OOP dan FP semua memiliki pola spesifik mereka.

Namun, ada beberapa pola yang sangat umum sehingga semua platform pemrograman yang dapat saya pikirkan seharusnya dimiliki. Berikut adalah daftar (tidak lengkap):

  • Adaptor. Saya hampir tidak dapat memikirkan platform pemrograman yang berguna yang begitu komprehensif (dan terpenuhi dengan sendirinya) sehingga tidak perlu berbicara dengan dunia. Jika akan melakukannya, adaptor pasti diperlukan.

  • Tatapan. Setiap platform pemrograman yang dapat menangani kode sumber besar harus dapat melakukan modularisasi. Jika Anda membuat modul untuk bagian lain dari program, Anda ingin menyembunyikan bagian "kotor" dari kode dan memberikannya antarmuka yang bagus.

  • Penerjemah. Secara umum, program apa pun hanya melakukan dua hal: input parse dan hasil cetak. Input mouse perlu diuraikan, dan widget jendela perlu dicetak. Oleh karena itu, memiliki interpreter yang tertanam memberi program kekuatan tambahan untuk menyesuaikan hal-hal.

Juga, saya perhatikan dalam bahasa FP yang khas, Haskell, ada sesuatu yang mirip dengan pola GoF, tetapi dengan nama yang berbeda. Menurut pendapat saya ini menyarankan mereka ada di sana karena ada beberapa masalah umum untuk diselesaikan dalam bahasa FP dan OOP.

  • Trafo dan dekorator Monad. Yang pertama digunakan untuk menambahkan kemampuan tambahan ke monad yang ada, yang terakhir menambahkan kemampuan tambahan ke objek yang ada.

1

Saya pikir setiap paradigma memiliki tujuan yang berbeda dan karena itu tidak dapat dibandingkan dengan cara ini.

Saya belum pernah mendengar bahwa pola desain GoF berlaku untuk setiap bahasa. Saya telah mendengar bahwa mereka berlaku untuk semua bahasa OOP . Jika Anda menggunakan pemrograman fungsional maka domain masalah yang Anda selesaikan berbeda dari bahasa OO.

Saya tidak akan menggunakan bahasa fungsional untuk menulis antarmuka pengguna, tetapi salah satu bahasa OO seperti C # atau Java akan membuat pekerjaan ini lebih mudah. Jika saya menulis bahasa fungsional maka saya tidak akan mempertimbangkan untuk menggunakan pola desain OO.


1

OOP dan FP memiliki tujuan berbeda. OOP bertujuan untuk merangkum kompleksitas / bagian yang bergerak dari komponen perangkat lunak dan FP bertujuan untuk meminimalkan kompleksitas dan ketergantungan komponen perangkat lunak.

Namun kedua paradigma ini tidak harus 100% saling bertentangan dan dapat diterapkan bersama untuk mendapatkan manfaat dari kedua dunia.

Bahkan dengan bahasa yang tidak mendukung pemrograman fungsional seperti C #, Anda dapat menulis kode fungsional jika Anda memahami prinsip FP. Anda juga dapat menerapkan prinsip-prinsip OOP menggunakan F # jika Anda memahami prinsip-prinsip OOP, pola, dan praktik terbaik. Anda akan membuat pilihan yang tepat berdasarkan situasi dan masalah yang Anda coba selesaikan, terlepas dari bahasa pemrograman yang Anda gunakan.


1

Beberapa pola lebih mudah diterapkan dalam bahasa yang mendukung FP. Sebagai contoh, Strategi dapat diimplementasikan menggunakan penutupan dengan baik. Namun tergantung pada konteksnya, Anda mungkin lebih suka menerapkan Strategi menggunakan pendekatan berbasis kelas, katakanlah di mana strategi itu sendiri cukup rumit dan / atau bagikan struktur yang ingin Anda modelkan menggunakan Metode Templat.

Dalam pengalaman saya mengembangkan dalam bahasa multi-paradigma (Ruby), implementasi FP bekerja dengan baik dalam kasus-kasus sederhana, tetapi di mana konteksnya lebih rumit, pendekatan berbasis OF GoF lebih cocok.

Pendekatan FP tidak menggantikan pendekatan OOP, itu melengkapi itu.


0

Karakteristik terpenting dari pemrograman fungsional, IMHO, adalah bahwa Anda memprogram dengan apa pun kecuali ekspresi - ekspresi dalam ekspresi di dalam ekspresi yang semuanya dievaluasi hingga ekspresi terakhir dan terakhir yang "menghangatkan mesin saat dievaluasi".

Karakteristik terpenting dari pemrograman berorientasi objek, IMHO adalah Anda memprogram dengan objek yang memiliki kondisi internal. Anda tidak dapat memiliki keadaan internal dalam fungsi murni - bahasa pemrograman berorientasi objek memerlukan pernyataan untuk membuat sesuatu terjadi. (Tidak ada pernyataan dalam pemrograman fungsional.)

Anda membandingkan apel dengan jeruk. Pola pemrograman berorientasi objek tidak berlaku untuk pemrograman fungsi, karena pemrograman fungsional adalah pemrograman dengan ekspresi, dan pemrograman berorientasi objek adalah pemrograman dengan keadaan internal.


Hmm, saya seharusnya memperhatikan bahwa pertanyaan itu sebelas tahun sebelum menjawab. :-)
Jim Flood

0

Kuatkan dirimu.

Ini akan memperburuk banyak untuk mendengar saya mengklaim telah mengganti pola desain dan menghilangkan prasangka SOLID dan KERING. Saya bukan siapa siapa. Namun demikian, saya benar memodelkan arsitektur kolaboratif (manufaktur) dan menerbitkan aturan untuk membangun proses online bersama dengan kode dan sains di baliknya di situs web saya http://www.powersemantics.com/ .

Argumen saya adalah bahwa pola desain berusaha untuk mencapai apa yang disebut manufaktur "kustomisasi massal", suatu bentuk proses di mana setiap langkah dapat dibentuk kembali, disusun ulang, dan diperluas. Anda mungkin menganggap proses seperti itu sebagai skrip yang tidak dikompilasi. Saya tidak akan mengulangi argumen (online) saya di sini. Singkatnya, arsitektur kustomisasi massal saya menggantikan pola desain dengan mencapai fleksibilitas itu tanpa semantik yang berantakan. Saya terkejut model saya bekerja dengan sangat baik, tetapi cara programmer menulis kode sama sekali tidak mempengaruhi bagaimana manufaktur mengatur kerja kolaboratif.

  • Pabrikan = setiap langkah berinteraksi dengan satu produk
  • OOP = setiap langkah berinteraksi dengan dirinya sendiri dan modul lain, melewati produk dari titik ke titik seperti pekerja kantor yang tidak berguna

Arsitektur ini tidak pernah membutuhkan refactoring. Ada juga aturan mengenai sentralisasi dan distribusi yang mempengaruhi kompleksitas. Tetapi untuk menjawab pertanyaan Anda, pemrograman fungsional adalah seperangkat semantik pemrosesan lain, bukan arsitektur untuk proses kustom massal tempat 1) perutean sumber ada sebagai dokumen (skrip) yang dapat ditulis ulang oleh pengguna sebelum menembak dan 2) modul dapat dengan mudah dan ditambahkan atau dihapus secara dinamis.

Kita dapat mengatakan bahwa OOP adalah paradigma "proses hardcoded" dan pola desain adalah cara untuk menghindari paradigma itu. Tapi itulah yang dimaksud dengan kustomisasi massal. Pola desain mewujudkan proses dinamis sebagai hardcode berantakan. Tidak ada gunanya. Fakta bahwa F # memungkinkan lewat fungsi sebagai parameter berarti fungsional dan OOP bahasa upaya sama-sama untuk mencapai kustomisasi massal itu sendiri.

Betapa membingungkan itu bagi pembaca, hardcode yang mewakili skrip? Tidak sama sekali jika Anda pikir konsumen kompiler Anda membayar untuk fitur tersebut, tetapi bagi saya fitur tersebut adalah pemborosan semantik. Mereka tidak ada gunanya, karena titik kustomisasi massal adalah untuk membuat proses itu sendiri dinamis , bukan hanya dinamis untuk programmer yang menggunakan Visual Studio.


0

Ya, dalam hal itu PL fungsional tingkat tinggi (seperti OCaml, dengan kelas, modul, dll.) Tentu saja menggantikan bahasa imperatif OOP dalam jenis fleksibilitas dan kekuatan ekspresi. Abstraksi tidak bocor, Anda dapat mengekspresikan sebagian besar ide Anda langsung di program. Oleh karena itu, ya, itu memang menggantikan pola desain, yang sebagian besar sangat sederhana dibandingkan dengan pola fungsional.

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.