Ketika saya berbicara di Internet, saya melihat satu fitur yang menarik. Semua paradigma pemrograman yang dibahas di tempat lain dirasakan oleh orang dengan cukup tenang. Jika, misalnya, mereka berbicara tentang pemrograman prosedural, maka mereka membicarakannya dengan sangat tenang. Hal yang sama adalah tentang pemrograman modular. Pemrograman deklaratif - tidak ada badai, kerusuhan atau holivarov. Pemrograman fungsional adalah sama.
Dan hanya di sekitar OOP jangan menenangkan badai.
Beberapa memekik darinya dalam kegembiraan, yang lain, sebaliknya, menemukan kesalahan pada apa yang menjadi dasar cahaya. Dan sejujurnya, saya benar-benar tidak mengerti mengapa seluruh dunia berkumpul di OOP.
Anda mungkin berpikir bahwa saya lebih sebagai lawan daripada penganjur OOP. Ini sama sekali tidak terjadi (namun, Anda dapat memahaminya dari judul). Tidak. Saya agak penentang peluru perak, hype, penobatan metodologi atau orang tertentu, dan semua jenis tarian bundar. Anda tidak bisa berkeliling menari, katakanlah, kunci pas atau mesin pemotong rumput. Dan jangan menulis, saya harap, publikasi mengapa bor atau palu menyebalkan.
Tapi hari ini seluruh Internet dipenuhi dengan artikel radikal, sombong, hiperemosional tentang OOP - jika ada yang mengatakan bahwa OOP adalah "zer gut" dan secara umum untuk semua usus, maka yang lainnya menyiarkan bahwa OOP perlu dibuang ke tempat sampah dengan segera (jika hanya dia tidak berbagi pandangan yang pertama). Tidak ada yang ketiga.
Saya hanya ingin memasukkan elemen ketiga. Tenang, tanpa hype dan penyalahgunaan, untuk mengatakan mengapa OOP bukan obat mujarab dari semua penyakit, tetapi juga, seperti PP, AF atau PL, memiliki hak untuk hidup.
Jadi, artikel yang tenang membela OOP. Di dalamnya, saya akan mencoba untuk mempertimbangkan argumen utama para penentang PLO dan membenarkan kegagalan mereka.
1. Segala sesuatu yang ada di OOP telah lama berada dalam paradigma lain
Hampir semua bahasa pemrograman turing-complete, dengan pengecualian bahasa markup, seperti HTML, XML, CSS, dll. Berbicara dalam bahasa petani, Turing adalah bahasa yang lengkap - bahasa di mana Anda dapat menulis program apa pun yang mungkin. Dari sini mengikuti tesis yang agak umum: apa yang ada dalam bahasa acak yang dipilih adalah dalam semua bahasa lain. Hal yang sama dapat dikatakan tentang paradigma. Semua perbedaan dalam bahasa (dan paradigma) adalah cara yang berbeda dalam mengimplementasikan perintah tertentu, tidak termasuk fitur leksikal individual.
Omong-omong, tesis yang sama ini (semua yang ada di N, ada di M, dan di K, dan di R, dll.) Dapat dirumuskan sebagai berikut: palu sudah terdiri dari besi dan kayu, mengapa kita juga membutuhkan tang? Tapi tidak ada yang akan mengatakannya.
2. OOP mencampur data dan tindakan mereka. Itu buruk
Argumennya tersedot keluar dari jari. Pertama, di mana OOP mencampur data dan fungsi? Kedua, pernyataan bahwa ini buruk juga diambil dari lentera, dari sebuah tong "seorang lelaki sejati tidak melakukan itu", dan mengapa - karena gladiol. OOP dalam beberapa hal memodelkan dunia nyata di mana data melekat pada objek - tidak ada yang akan berpendapat bahwa kursi tersebut hilang warna dan tidak memiliki empat kaki. Dan tidak ada pencampuran data dan operasi yang terjadi di sini, objeknya bukan fungsi atau operator.
Ini adalah abstraksi.3. Warisan memperbudak program, membuat perubahan sulit
Di sini Anda bisa sedikit melambat. Warisan sama sekali tidak menyiratkan pembangunan pohon panjang kilometer untuk memperlambat pembangunan. Warisan diciptakan untuk membedakan properti umum dan metode menjadi kelas super, dan ini harus dilakukan dengan kelas yang mewakili objek dari jenis yang sama. Ini akan menjadi kesalahan untuk membuat, misalnya, dua kelas, salah satunya adalah pewaris yang lain, karena tidak ada alokasi kode umum untuk superclass hanya karena
tidak ada kesamaan .
Jika tidak dimaksudkan untuk memperluas kelas induk ke kelas ketiga, warisan seperti itu tidak ada artinya. Jika Anda membuat toko minuman keras, maka kelas Bir, Vodka, dan Vine dapat diwarisi dari kelas Alkohol, tetapi Anda tidak perlu membuat kelas Minuman sama sekali, kecuali jika Anda ingin menjual, katakanlah, teh Paraguay.
Juga, itu akan menjadi kesalahan untuk membuat hierarki di mana kelas tidak berhubungan satu sama lain. Nah, mengapa, beri tahu saya, untuk membuat menara tempat kelas Terbang dan Cutlet diwarisi dari keju superclass, yang, pada gilirannya, diwarisi dari superclass Friday?! Tapi ini bukan lagi cacat OOP, tetapi tangan bengkok dari orang yang menyusunnya.
4. Enkapsulasi tidak masuk akal
Di sini saya sebagian setuju. Dari sudut pandang program, enkapsulasi benar-benar tidak mempengaruhi apa pun. Jika saya menutup variabel menggunakan pribadi - jadi apa, saya masih bisa membukanya dengan hanya menghapus pribadi, dan kemudian mengubah semua yang ada yang saya suka.
Tetapi ini hanya benar secara teknis. Filosofi OOP adalah bahwa kelas yang terorganisir dan dikemas dengan benar dapat dilihat sebagai kotak hitam. Bayangkan sebuah kotak di satu sisi di mana terdapat berbagai tombol, slot untuk memasok data, dan di sisi lain - slot keluaran yang mengembalikan informasi. Ambil, misalnya, tumpukan. Bayangkan sebuah kotak di satu sisi di mana ada satu slot untuk memasukkan data dan tombol tekan di sebelahnya. Di bagian belakang adalah tombol pop. Anda mengirimkan catatan dengan nomor 8 dan menekan tombol push. Kemudian Anda memberikan selembar kertas lagi dan menekan tombol untuk kedua kalinya. Jadi N kali, dan kemudian tekan pop. Selembar kertas terbang keluar dari laci dengan nomor 76 (atau yang lain, secara umum, yang Anda kirimkan). Perlu nomor lain? Tekan pop untuk kedua kalinya. Demikian seterusnya hingga
konspirasi wortel hingga kotaknya kosong. Dan jika Anda terus menekan pop, mekanisme dari kotak akan menaklukkan: tumpukan kosong! Ini persis seperti apa objeknya.
Tetapi setelah Anda membuat dan mengonfigurasikan kelas, itu sudah ungu bagi Anda cara kerjanya - itu hanya berfungsi dengan benar, tetapi Anda tidak perlu berharap untuk lebih. Dan merangkum semua struktur ini, Anda tidak menyimpan semuanya dalam ingatan. Mereka (banyak kotak) hanya berbicara satu sama lain dengan cara Anda mengatur.
Enkapsulasi adalah semacam penopang yang mendukung ratusan pilar program Anda saat Anda membangun seratus dan pertama. Dalam proyek-proyek besar (yaitu, untuk menciptakannya, OOP diciptakan) tanpa ini, sayangnya, tidak ada apa-apa.
Meskipun, hampir tidak "sayangnya" umumnya sesuai di sini.
5. Tidak ada hierarki hubungan di dunia nyata, hanya hierarki inklusi di mana-mana
Benarkah begitu? Tetapi tidak ada yang mengganggu untuk menciptakan, misalnya, hierarki di mana semua sungai di dunia (Kongo, Seine, Thames, Amazon, Kolyma, dll.) Adalah objek dari satu "Sungai" yang komprehensif, yang memiliki sifat-sifat yang melekat (misalnya, terdiri dari air) dan tindakan (misalnya, mengalir), dan itu sudah akan diwarisi dari "Kolam", yang juga terdiri dari air, dan dari "Kolam" Anda juga dapat mewarisi "Danau", benda-benda yang akan menjadi danau yang terpisah (Baikal, Laut Kaspia, Titicaca, dll. .d.). Skema ini cukup kasar. Tetapi hierarki hubungan juga merupakan
abstraksi . Sesuatu yang ide Platonis, jika Anda mau. Di dunia nyata mereka tidak ada di sana, mereka hanya ada dalam pikiran, ini adalah generalisasi, dan tidak lebih. Tetapi justru inilah yang sering dipikirkan seseorang. Kita dapat mengatakan "kaus kaki" tanpa menentukan warna apa itu, bahan apa yang ditenun, dll., Tetapi apakah "kaus kaki" ini benar-benar ada?
Meskipun demikian, kita tidak boleh malu bahwa tidak ada "objek" atau "kaus kaki".
6. Metodologi OOP awalnya salah
Argumen yang benar-benar tidak berdasar. OOP dibuat untuk mensimulasikan semacam dunia virtual yang terdiri dari objek, seperti dunia kita. Sebagai contoh: seseorang adalah objek dari dunia nyata. Dia bisa berjalan, berlari, makan,
buang air besar , bermain sepak bola, menonton sepak bola, tetapi, sayangnya, saya tidak bisa mendaftar semuanya di sini, dan jujur, itu menjijikkan untuk mendaftar semuanya. Orang yang sama ini memiliki sifat-sifat berikut: ada / tidaknya rambut, warna rambut, jika ada, warna mata,
jika mereka warna kulit, jumlah jari, dll. Jika Anda benar membangun semua bidang dan metode, seperti yang saya tulis di atas, objek program akan dapat memodelkan properti tertentu dari objek nyata. Seseorang berpikir sangat baik dalam kategori seperti itu - itulah sebabnya OOP telah menyebar luas. Ini sangat membantu ketika menulis proyek besar, karena memperkenalkan modularitas dan memungkinkan Anda untuk memecah paket perangkat lunak menjadi komponen terpisah yang berinteraksi satu sama lain.
7. Tetapi bahkan jutaan lalat tidak akan meyakinkan kita bahwa kotoran itu lezat.
Argumen paling populer terhadap OOP. Seperti, massa kebanyakan bodoh (namun saya tidak berpikir bahwa ini berlaku untuk programmer juga), berkeliaran di "pakaian modis" dan mengagumi mereka.
Tapi coba pikirkan, dan kalau bukan PLO, tapi, katakanlah, LP, sudah masuk alas? Apakah Anda pikir itu akan berbeda? Tidak ada yang semacam itu! Akan ada penggemar dan lawan jahat, dan mereka akan melihat PLO sebagai instrumen (untuk ini, saya benar-benar menyerukan), dan bukan sebagai pil yang diciptakan oleh Tuhan sendiri dan karenanya tidak tergantikan.
Mengapa artikel ini membela PLO?
Semua pembicaraan modern tentang paradigma pemrograman, seperti yang saya lihat, turun ke dua premis berdiameter: tinggalkan OOP dan buang sisanya, atau buang OOP dan ... yah, Anda mengerti saya.
Saya tidak ingin paradigma yang benar-benar cocok untuk dianggap sebagai dump yang layak, tetapi saya tidak ingin menari di sekitarnya, tetapi lupa segalanya. Saya pikir yang kedua lebih mudah dilakukan, tetapi artikel ini diarahkan yang pertama.
Jika Anda tidak suka OOP
Kepada siapa - OOP, kepada siapa - FP, kepada siapa - PP. Dan bagi seseorang, mungkin, secara umum, tulang rawan babi paling manis. Jika Anda tidak suka kucing, Anda mungkin tidak tahu cara memasaknya.