Apakah pemrograman fungsional menggantikan pola desain GoF?

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?

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. ;)

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.

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.

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

Pola Desain dalam Pemrograman Dinamis oleh Peter Norvig memiliki liputan mendalam tentang tema umum ini, meskipun tentang bahasa 'dinamis' alih-alih 'fungsional' (ada tumpang tindih).

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.

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.)

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.

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.

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.

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".

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".

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.

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.

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.

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.

Intinya ya !

• Ketika sebuah pola mengelak dari fitur yang hilang (fungsi urutan tinggi, penanganan aliran ...) yang akhirnya memudahkan komposisi .
• Kebutuhan untuk menulis ulang implementasi pola berulang kali dapat dilihat sebagai bau bahasa .

Selain itu, halaman ini (AreDesignPatternsMissingLanguageFeatures) menyediakan tabel terjemahan "pola / fitur" dan beberapa diskusi yang bagus, jika Anda bersedia untuk menggali.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.