Halo, Habr! Saya berikan kepada Anda terjemahan sebuah artikel oleh
Roman Provaznik -
Mengapa FP penting bahkan bagi pengembang OOP?Setelah saya sangat tertarik dengan pemrograman fungsional, saya mulai mempelajarinya dan memberi tahu semua teman saya tentang betapa indahnya itu. Kemudian saya menemukan sebuah artikel tentang pemrograman fungsional dari sudut pandang seorang programmer OOP dan memutuskan untuk menerjemahkannya untuk Anda. Jangan menilai dengan ketat, ini adalah terjemahan pertama saya.
Saya diminta untuk memberikan pendapat pribadi tentang pemrograman fungsional dari sudut pandang berorientasi obyektif. Saya bahkan terpaksa membuat akun di Medium. Sebagai seorang mantan pengembang OOP dan saat ini, suatu hari saya akan menjadi programmer FP nyata, saya pikir saya punya sesuatu untuk dikatakan:
Selamat datang wisatawan
Jika Anda belum menghabiskan 60 tahun terakhir di planet lain (jika demikian, selamat datang kembali, pelancong), Anda mungkin pernah mendengar tentang pemrograman fungsional. Jika Anda mengikuti tren saat ini di industri perangkat lunak, Anda akan mendengar istilah seperti "pemrograman fungsional", "ketidakmampuan", "fungsi murni" dan "komposisi" setiap hari. Semua ini terdengar keren, menyenangkan dan dapat dipahami sampai Anda berpikir: "Hei, saya seorang programmer OOP dan saya tidak bisa (atau tidak mau) mengubah paradigma. Apa yang bisa diberikan pemrograman fungsional kepada saya? Kenapa saya harus repot? " Sebagai seorang programmer / penggila FP yang datang dari dunia OOP, saya ingin membagikan apa yang ingin saya ketahui bertahun-tahun yang lalu. Anda dapat membicarakan hal ini selama berjam-jam, jadi mari kita pilih tiga hal terpenting.
Kekekalan
Keuntungan tradisional dari FP adalah kata, yang biasanya membutuhkan setidaknya dua slide dari setiap presentasi tentang pemrograman fungsional. Peluru perak FP, kan? Tidak juga. Terlepas dari kenyataan bahwa kata ini paling sering digunakan terutama oleh programmer fungsional, itu tidak eksklusif untuk FP. Sebagai pengembang OOP, Anda dapat mencapai (hampir) tingkat ketidakberimbangan yang sama dengan pengembang FP. Sebenarnya, ini cukup mudah, Anda hanya perlu melihat sedikit berbeda pada objek dan koleksi Anda. Bayangkan Anda tidak mengubah aslinya, tetapi membuat versi baru. Menambahkan item ke koleksi? Hebat! Anda belum mengubah koleksi asli, melainkan Anda hanya memiliki koleksi baru yang berisi item yang ditambahkan. Mengubah properti suatu objek? Wow! Sekarang Anda memiliki objek baru dengan properti yang diubah.
Saya tahu, saya tahu - kedengarannya aneh. Tetapi perubahan kesadaran kecil ini akan memungkinkan Anda untuk tidur lebih tenang. Segera setelah Anda memahami bahwa objek Anda tidak dapat diubah (hanya disalin), Anda akan yakin bahwa tidak seorang pun di tim akan dapat menugaskan kembali mereka di tempat lain. Ini seperti meminjam kaset audio Pink Floyd kuno favorit Anda tanpa takut direkam ulang dengan Justin Bieber. Dan sebagai bonus, kode Anda akan memiliki metode yang sepenuhnya dapat dilacak di mana perubahan nyata terjadi (di mana objek baru dibuat berdasarkan yang asli). Dan, saya hampir lupa jika Anda adalah pengembang C # atau Java, Anda sudah menggunakannya dengan memanggil "ToLower ()", "Trim ()" pada baris yang awalnya tidak dapat diubah. Itu pada dasarnya bukan hal baru.
Fungsi murni
Ungkapan modis lain yang keliru dianggap sebagai FP eksklusif. Apa itu "fungsi murni"? Sederhananya, fungsi murni adalah fungsi yang mengembalikan hasil yang sama dengan nilai input yang sama, tanpa komunikasi dengan "dunia luar" (operasi I / O, status umum, dll.), Juga dikenal sebagai "efek samping". Contoh khas dari jenis fungsi ini bisa mendapatkan panjang string (Anda tidak akan terhubung ke database untuk menghitung jumlah karakter dalam string?), Menghitung sinus, dan sebagainya. Apa manfaatnya bagi OOP? Sama seperti untuk FP. Jika Anda bekerja dengan fungsi murni (atau metode), Anda tahu persis hasil apa yang akan Anda dapatkan untuk setiap nilai input. Dan jika kode Anda tidak bergantung pada beberapa kondisi tersembunyi, sangat mudah untuk menguji, dan Anda tidak akan repot-repot menulis unit test. Kita semua tahu bahwa tanpa berinteraksi dengan dunia luar, perangkat lunak kami tidak akan berguna, tetapi ada perbedaan nyata antara kode murni (ditulis dengan fungsi / metode murni) dengan input-output hanya di perbatasan sistem dan sistem di mana masing-masing metode tergantung pada keadaan internal, diperbarui dengan metode lain.
Sekali lagi, sedikit memikirkan kembali pendekatan I / O memberikan semua keuntungan FP, ditambah pengujian menjadi sangat sederhana sehingga akhirnya akan mulai membawa kesenangan.
Deklaratif VS Imperatif
Kami telah mengubah sudut pandang pada kode kami - kami dapat menulis kode yang lebih aman (tidak berubah) dan dapat diuji (bersih). Sekarang saatnya untuk melangkah lebih jauh dan mengubah pendekatan untuk menentukan apa yang harus dilakukan oleh perangkat lunak kami. Apa lagi yang membuat OOP sangat berbeda dari AF? Dalam dunia fungsional, kita mendefinisikan "apa" yang harus terjadi alih-alih menentukan "bagaimana" seharusnya terjadi. Tentu saja, tetap ada bagian dari program yang melakukan operasi tertentu, tetapi di sini penting untuk berkonsentrasi pada ekspresi daripada pernyataan. Dan inilah yang dapat Anda lakukan dalam bahasa OOP favorit Anda.
Misalnya, jika Anda terbiasa dengan hal-hal seperti LINQ (dari C #), Anda sudah tahu manfaat dari ekspresi kueri ketika Anda dapat membaca kode Anda sebagai “Ya, di sini saya mengambil 10 elemen dari koleksi, mengurutkannya berdasarkan abjad dan menggunakannya sebagai parameter untuk berikut ini metode. " Anda mungkin telah membaca ribuan ekspresi seperti LINQ tanpa harus memikirkan apa yang sebenarnya terjadi di balik layar. Dan yang paling penting adalah berkonsentrasi pada apa yang benar-benar penting.
Ringkasan
Saya pikir itu sudah cukup untuk saat ini. Saya tidak ingin akhirnya menjual FP sebagai peluru perak. Dunia tidak hanya hitam dan putih. Yang benar adalah bahwa FP sangat sulit bagi saya. Hampir serumit OOP yang tepat. Tapi itu pasti patut dicoba. Dari sudut pandang saya, OOP vs FP, pada umumnya, cara saya berpikir tentang kode dan strukturnya. Bagaimana saya memikirkan dependensi, efek samping, seluruh dunia I / O dan pengujian. Untuk meringkas dengan satu pemikiran, "Pendekatan fungsional akan membantu, terlepas dari bahasa, area subjek dan platform."