Pemrograman fungsional vs. pemrograman imperatif (LINQ ke XML)

Artikel ini membandingkan dan membandingkan pemrograman fungsional dengan pemrograman imperatif (prosedural) yang lebih tradisional.

Pemrograman fungsional vs. pemrograman imperatif

Paradigma pemrograman fungsional dibuat secara eksplisit untuk mendukung pendekatan fungsional murni untuk pemecahan masalah. Pemrograman fungsi adalah bentuk pemrograman deklaratif. Sebaliknya, sebagian besar bahasa mainstream, termasuk bahasa pemrograman berorientasi objek (OOP) seperti C#, Visual Basic, C++, dan Java, dirancang untuk terutama untuk mendukung pemrograman imperatif (prosedural).

Dengan pendekatan imperatif, pengembang menulis kode yang menentukan langkah-langkah yang harus diambil komputer untuk mencapai tujuan. Ini terkadang disebut sebagai pemrograman algoritmik. Sebaliknya, pendekatan fungsional melibatkan penyusunan masalah sebagai satu set fungsi yang akan dieksekusi. Anda menentukan dengan cermat input untuk setiap fungsi, dan apa yang dikembalikan oleh setiap fungsi. Tabel berikut menjelaskan beberapa perbedaan umum antara kedua pendekatan ini.

Karakteristik Pendekatan imperatif Pendekatan fungsional
Fokus pemrogram Cara melakukan tugas (algoritma) dan cara melacak perubahan status. Informasi apa yang diinginkan dan transformasi apa yang diperlukan.
Status Perubahan Penting. Tidak ada.
Urutan eksekusi Penting. Kepentingan rendah.
Kontrol aliran primer Perulangan, kondisional, dan panggilan fungsi (metode). Panggilan fungsi, termasuk rekursi.
Unit manipulasi primer Contoh struktur atau kelas. Berfungsi sebagai objek kelas satu dan kumpulan data.

Meskipun sebagian besar bahasa dirancang untuk mendukung paradigma pemrograman tertentu, banyak bahasa umum yang cukup fleksibel untuk mendukung beberapa paradigma. Misalnya, sebagian besar bahasa yang berisi penunjuk fungsi dapat digunakan untuk mendukung pemrograman fungsional secara kredibel. Selain itu, C# dan Visual Basic menyertakan ekstensi bahasa eksplisit untuk mendukung pemrograman fungsional, termasuk ekspresi lambda dan inferensi jenis. Teknologi LINQ adalah bentuk program deklaratif dan fungsional.

Pemrograman fungsional menggunakan XSLT

Banyak pengembang XSLT akrab dengan pendekatan fungsional murni. Cara paling efektif untuk mengembangkan lembar gaya XSLT adalah dengan memperlakukan setiap templat sebagai transformasi yang terisolasi dan dapat disusun. Urutan eksekusi benar-benar tidak ditekankan. XSLT tidak memungkinkan efek samping (dengan pengecualian bahwa mekanisme pelepasan untuk mengeksekusi kode prosedural dapat memperkenalkan efek samping yang mengakibatkan ketidakmurnian fungsional). Namun, meskipun XSLT adalah alat yang efektif, beberapa karakteristiknya tidak optimal. Misalnya, mengekspresikan konstruksi pemrograman dalam XML membuat kode relatif bertele-tele, dan karena itu sulit untuk dipertahankan. Juga, ketergantungan besar pada rekursi untuk kontrol aliran dapat menghasilkan kode yang sulit dibaca. Untuk informasi selengkapnya tentang XSLT, lihat Transformasi XSLT.

Namun, XSLT telah membuktikan nilai menggunakan pendekatan fungsional murni untuk mengubah XML dari satu bentuk ke bentuk lainnya. Pemrograman fungsional murni dengan LINQ ke XML mirip dalam banyak hal dengan XSLT. Namun, konstruksi pemrograman yang diperkenalkan oleh LINQ ke XML, C#, dan Visual Basic memungkinkan Anda untuk menulis transformasi fungsional murni yang lebih mudah dibaca dan dapat dipertahankan daripada XSLT.

Keuntungan dari fungsi murni

Alasan utama untuk menerapkan transformasi fungsional sebagai fungsi murni adalah bahwa fungsi murni dapat disusun: yaitu, mandiri dan tanpa status. Karakteristik ini membawa sejumlah manfaat, termasuk yang berikut:

  • Peningkatan keterbacaan dan pemeliharaan. Ini karena setiap fungsi dirancang untuk menyelesaikan tugas tertentu mengingat argumennya. Fungsi ini tidak bergantung pada keadaan eksternal.
  • Pengembangan berulang yang lebih mudah. Karena kode lebih mudah untuk melakukan refaktor, perubahan desain seringkali lebih mudah untuk menerapkan. Misalnya, misalkan Anda menulis transformasi yang rumit, dan kemudian menyadari bahwa beberapa kode diulang beberapa kali dalam transformasi. Jika Anda melakukan refaktor melalui metode murni, Anda dapat memanggil metode murni Anda sesuka hati tanpa khawatir tentang efek samping.
  • Pengujian dan debugging yang lebih mudah. Karena fungsi murni dapat lebih mudah diuji secara terpisah, Anda dapat menulis kode uji yang memanggil fungsi murni dengan nilai khas, kasus tepi yang valid, dan kasus tepi yang tidak valid.

Transisi untuk pengembang OOP

Dalam pemrograman berorientasi objek tradisional (OOP), sebagian besar pengembang terbiasa dengan pemrograman dalam gaya imperatif/prosedural. Untuk beralih ke pengembangan dalam gaya fungsional murni, mereka harus membuat transisi dalam pemikiran mereka dan pendekatan mereka terhadap pembangunan.

Untuk memecahkan masalah, pengembang OOP merancang hierarki kelas, fokus pada enkapsulasi yang tepat, dan berpikir dalam hal kontrak kelas. Perilaku dan keadaan jenis objek adalah yang terpenting, dan fitur bahasa, seperti kelas, antarmuka, warisan, dan polimorfisme, disediakan untuk mengatasi masalah ini.

Sebaliknya, pemrograman fungsional mendekati masalah komputasi sebagai latihan dalam evaluasi transformasi fungsional murni dari pengumpulan data. Pemrograman fungsional menghindari status dan data yang dapat berubah, dan sebaliknya menekankan penerapan fungsi.

Untungnya, C# dan Visual Basic tidak memerlukan lompatan penuh ke pemrograman fungsional, karena mereka mendukung pendekatan pemrograman imperatif dan fungsional. Pengembang dapat memilih pendekatan mana yang paling tepat untuk skenario tertentu. Bahkan, program sering menggabungkan kedua pendekatan.

Lihat juga