Saatnya melepaskan diri dari OOP
OOP dianggap sebagai berlian terbesar di mahkota ilmu komputer. Cara terbaik untuk mengatur kode Anda. Solusi untuk semua masalah. Satu-satunya cara pasti untuk menulis program kami. Dewa pemrograman mengirim kami dari atas ... Hanya di sini programmer OOP dipaksa untuk mengumpulkan semua jenis abstraksi, melacak semua objek bersama, mengingat banyak "pola pemrograman" - dan menghabiskan waktu dan energi mereka untuk semua ini daripada memecahkan masalah itu sendiri.
Banyak yang telah lama mengkritik OOP, dan ada banyak programmer yang sangat dihormati di antara kritik tersebut. Dan bahkan Alan Kay - penemu OOP ada di jajaran mereka!
Tujuan utama setiap pengembang adalah menulis kode yang dapat diandalkan. Jika kodenya bermasalah dan tidak berfungsi sebagaimana mestinya, maka tidak ada lagi yang penting. Apa cara terbaik untuk menulis kode yang dapat diandalkan? Buat kodenya tetap sederhana. Kesederhanaan adalah kebalikan dari kompleksitas . Oleh karena itu, tujuan utama pengembang adalah mengurangi kompleksitas kode.
Penafian:
Saya bukan penggemar OOP, jadi tidak mengherankan jika artikel ini tampak bias bagi banyak orang. Namun, saya akan memberikan argumen untuk mempertahankan posisi saya.
Saya juga mengerti betul bahwa kritik terhadap OOP sangat menyakitkan bagi banyak orang. Begitu banyak pembaca akan merasa tersinggung secara pribadi. Namun, saya bermaksud untuk menyatakan apa yang saya yakini benar. Karena tujuan saya bukan untuk menyinggung, tetapi untuk menunjukkan masalah yang dimiliki OOP. Saya tidak mengkritik Alan Kay
's OOP . Dia umumnya jenius. Secara pribadi, saya ingin OOP persis seperti yang diinginkan Alan Kay. Yang saya kritik adalah OOP dalam implementasi C # atau Java.
Masalahnya adalah OOP telah lama dianggap sebagai standar untuk mengatur kode perangkat lunak. Dan begitu banyak orang berpikir, termasuk mereka yang memegang posisi serius di industri perangkat lunak, itulah sebabnya pendekatan pemrograman lain bahkan tidak dipertimbangkan di sebagian besar perusahaan.
Saya harus mengatasi banyak kesulitan ketika saya menulis dalam bahasa OOP. Dan saya selalu bertanya-tanya mengapa kesulitan ini muncul. Mungkin saya tidak terlalu baik? Mungkin saya perlu mempelajari beberapa lusin "pola pemrograman" lagi? Pada akhirnya, saya hanya tidak memiliki kekuatan yang tersisa untuk semua ini.
Artikel ini akan memberi tahu Anda perjalanan panjang satu dekade saya beralih dari OOP ke pemrograman fungsional. Sejak itu, saya tidak ingat kasus ketika saya menemukan proyek yang OOP paling cocok. Selain itu, proyek-proyek di mana OOP digunakan berada di bawah beban kompleksitas kode - dari beberapa titik tidak mungkin untuk mempertahankan dan mengembangkannya lebih lanjut.
TLDR
"Program berorientasi objek adalah alternatif dari program yang tepat."
Edsger W. Dijkstra, pelopor ilmu komputer
Tujuan OOP adalah satu - untuk mengatasi kompleksitas kode prosedural. Dengan kata lain, OOP dirancang untuk meningkatkan organisasi kode. Namun sejak saat itu belum ada bukti bahwa OOP lebih baik dari program prosedural lama.
Kebenaran pahit adalah bahwa OOP tidak melakukan satu hal yang dirancang untuk dilakukan. Semuanya tampak hebat di atas kertas - kami memiliki hierarki yang ketat dari hewan, anjing, orang ... (Dan, tentu saja, bentuk: persegi panjang, kotak, dan lingkaran - kemana kita bisa pergi tanpanya!) Tetapi karena kompleksitas kode aplikasi meningkat, OOP tidak membantu menguranginya , tetapi sebaliknya meningkat - dengan banyak "pola pemrograman" yang diperlukan dan menyulitkan programmer untuk melacak di mana dan bagaimana nilai variabel berubah. OOP membuat banyak prosedur yang umum digunakan, seperti refactoring dan pengujian, menjadi rumit yang tidak perlu.
Banyak orang tidak setuju dengan saya, tetapi kenyataannya adalah bahwa desain OOP di C # atau Java tidak dipikirkan secara ilmiah, itu bukan hasil penelitian ilmiah yang serius. Tidak seperti pemrograman fungsional, misalnya, di Haskell, di mana kalkulus lambda adalah fondasi teoretis yang kokoh. OOP tidak didasarkan pada hal seperti itu.
Dalam proyek kecil, OOP bekerja dengan cukup baik. Tetapi apa yang terjadi ketika proyek berkembang? OOP adalah bom waktu yang pasti akan meledak saat kode proyek mencapai ukuran tertentu. Proyek mulai terlambat, tenggat waktu gagal, pengembang kehabisan energi, dan menambahkan fitur baru menjadi hampir mustahil. Pada akhirnya, perusahaan terpaksa menandai kode tersebut sebagai "usang" dan memaksa pengembang untuk menulis ulang.
OOP sangat tidak cocok dengan cara otak kita berpikir. Kita terbiasa fokus pada tindakan: jalan-jalan, berbicara dengan teman, makan pizza. Otak kita telah berevolusi ke arah "melakukan sesuatu", dan bukan ke arah membangun hierarki objek abstrak yang kompleks.
Kode OOP adalah non-deterministik (tidak seperti pemrograman fungsional): kami tidak dapat memastikan bahwa dengan data masukan yang sama, kami akan mendapatkan hasil yang sama setiap saat. Ini membuatnya sangat sulit untuk memahami cara kerja program. Berikut contoh sederhananya: bandingkan 2 + 2 dan kalkulator. Tambahkan (2, 2) . Ekspresi terakhir, secara teori, harus selalu mengembalikan 4, tetapi dapat mengembalikan 5, 3, atau bahkan 1004, karena dependensi objek Calculator dapat mengubah perilakunya dengan cara yang paling tidak terduga.