Mistik Bahasa OOP yang Berbahaya

Berikut adalah beberapa contoh dari mistik (miss-perception) Bahasa OOP yang jelek, karena lebih banyak menimbulkan salah persepsi dibandingkan manfaatnya. Beberapa bahkan betul-betul jelek karena menghancurkan konsep Lokalisasi (konsep terpenting dari OOP).


1.1. Operator Overloading

Operator Overloading hanya betul-betul diperlukan di kasus tertentu yang sangat sedikit jumlah. Akan tetapi fitur ini ”sangat merangsang” para developer untuk menggunakannya karena dipandang sangat “cool”. Akibatnya lebih banyak ajeb-nya daripada manfaat-nya. Fitur ini dengan gampang disubtitusi menggunakan function call seperti biasa DAN INI BAHKAN LEBIH TERANG-BENDERANG. Dengan Operator Overloading, kita tidak pernah yakin apakah ”+” hanya berarti ”+” bukan merupakan operasi penggabungan alokasi memori (yang mempunyai impact sangatlah dasyat). Ini bahkan menghancurkan konsep Lokalisasi. Kenapa? Karena tujuan dari konsep Lokalisasi adalah supaya code kita terang-benderang, jelas mana aja yang harus diubah, dan mana yang tidak boleh diubah, A ya A. Tx to Operator Overloading, A belum tentu A lagi.

1.2. Get-Set Evil Duo

That is sooo coooool, sehingga sebagian developer merasa cool kalau semua variable dibuat sebagai get-set. Yang terbaik dari pemikiran ini adalah membuat mata sakit.

Klo ada sebuah variable bisa di-set dan di-get, ya itu namanya public variable. Klo tidak punya get dan set sama sekali, namanya private variable. Kedua ini sudah ada syntaxnya (yg jauh lebih sederhana) sejak jaman baheula. Klo hanya bisa di-get, berarti hanya bisa dibaca, ini namanya read-only variable, baru agak baru dan sedikit ada gunanya. Agak baru karena inipun dengan mudah dilakukan dengan menggunakan sebuah fungsi biasa (misal : GetProcessorDate).

Dan yang bahaya, adalah sebuah statement kecil meng-assign sebuah variable, bisa berujung kepada access ke database server di sebuah server nun jauh dimana. Ini namanya tidak terang-terangan. Menggunakan bahasa OOP supaya code lebih manageable, tapi untuk yang dari dulu sudah ok, malah dibuat jadi lebih rumit karena ngotot mau programming “pure” OOP.

1.3. Black Box

Oleh beberapa orang yang sangat kreatif, omong kosong dari Encapsulation “disempurnakan” lebih lanjut menjadi konsep Black Box. Apa itu? Bahwa dengan Encapsulation kita tidak perlu lagi peduli dengan code dari fungsi yang kita panggil. Ini jelas Salah Besar.

Arti yang sebenarnya dari Black Box, adalah kita jangan mengutak-atik isi dari sebuah fungsi (anw note : fitur private variable tidak menghalangi kita untuk mengutak-atik sebuah private variable, misalnya dengan teknik direct-memory-access). TETAPI BUKAN KITA TIDAK USAH PEDULI MAUPUN TIDAK PERLU TAHU MENGENAI ISI DARI FUNGSI YANG KITA PANGGIL.

Untuk menggunakan Handphone, Anda harus tahu jelas apa gunanya Handphone, dan punya pengertian cukup mengenai bagaimana cara kerja Handphone. Sama saja, dan sangat masuk akal sehat, kalau mau menggunakan sebuah fungsi, mengertilah dulu mengenai fungsi tersebut. Jika baca dari API Guide sudah cukup, fine, jika masih belum jelas, lihat langsung ke source-code-nya.

Terima-kasih sebanyak-banyaknya terhadap orang-orang kreatif tersebut, karena Software Developer yang MALAS mempunyai landasan mistik kuat untuk tidak membaca / mengerti source-code dari sebuah fungsi L

1.4. Antisipasi untuk Masa Depan

OOP terhitung bahasa modern, masa depan-lah. Developer yang gak menguasai OOP berarti ketinggalan jaman. That is ok-lah. Yang jadi masalah adalah developer menjadi super kreatif, sehingga kalau programming, selalu berpikir ini untuk antisipasi masa depan… alhasil banyak code-code yang tidak dipakai sekarang, tapi NANTI untuk masa depan.

SATU FAKTA YANG SUDAH JELAS (di masa sekarang) : code menjadi tambah rumit untuk sesuatu di masa depan. Antisipasi masa depan adalah bagus, yang salah ada pemahaman mengenai apa yang dimaksud di masa depan. Sebuah logika sederhana yang dipatut direnungkan : kalau Anda mengatakan antisipasi masa depan, seberapa jauhkah? Kalau membuat aplikasi ERP, apakah mau disiapkan ke depan sampai dengan setara dengan SAP, atau bahkan lebih? Kalau membuat sebuah sistem di perusahaan yang sudah menggunakan SAP, apakah mau diantisipasi sehingga bisa berjalan juga kalau perusahaan itu berubah menggunakan Oracle Applications? Kalau membuat aplikasi untuk Windows, apakah disiapkan supaya bisa jalan di Linux, Apple, Sun OS, SCO Unix, bisa di-web-kan, AS/400 (kali2 aja ngetop lagi), atau lebih hebat sekalian disiapkan untuk jalan di Palm, atau bahkan jalan di iPod?? Think again!! Apakah bisa kita memprediksi masa depan, apakah bisa kita tahu bahwa tahun depan market menginginkan apa. ITU HANYA ILUSI.

Yang dimaksud antisipasi masa depan, adalah buat code seterang-terang-benderang-nya, se-standar-standar-nya, se-simple-simple-nya, tetapi UNTUK KEBUTUHAN MASA SEKARANG SAAT INI JUGA, supaya kalau nanti mau di-upgrade gampang. Bukan mengarang-ngarang fitur-fitur masa depan dalam masa sekarang. For God sake, kita adalah Software Developer, bukan ahli nujum. Jangan terjebak dalam ilusi tersebut.

Wahyudi Blog

 *.:｡✿ Don't forget to come back again ✿.｡.:*

Visit Wahyudi Blog !