Lahirnya OOP dan Bahasa OO

1.1. Lahirnya OOP dan Bahasa OO

OOP dan bahasa OO kaya dengan berbagai macam fitur yang sangat baik untuk programming.
Membahas itu semua di luar dari konteks artikel ini. Jadi kita akan membahas satu saja yang paling
popular yaitu fitur : class dan inheritance-nya. Kita akan bahas dari “mengapa”-nya. Diharapkan dengan
demikian, selanjutnya tentu kita bisa menarik kesimpulan sendiri apa gunanya dari fitur-fitur yang lain.

Untuk memahami contoh berikut, sebaiknya dibuang dulu pemikiran mistik, bahwa kita harus mengganti
pola pikir flow / step-by-step menjadi pola pikir class dan inherintance. Jangan percaya omong kosong
ini. Mengapa? Tujuan kita tidak berubah dari jamannya Von Newman 100 tahun lalu, yaitu : membuat
instruksi step-by-step untuk komputer. Jadi yang betul adalah kita harus tetap berangkat dari pola pikir
flow / step-by-step ini, kemudian kita lihat dimana class bisa membantu kita menulis instruksi dengan
lebih efisien. Baru setelah itu lama-lama kita akan terbiasa sehingga class menjadi daya reflex kita.
Seperti halnya membuat fungsi, menulis variable, looping, array, dan seribu satu macam trick-trick
programming menjadi daya reflex kita. TETAPI BUKAN LONCAT, UBAH POLA PIKIR MENJADI CLASS.
Dengan cara begitu, sampai matipun saya yakin tidak akan pernah memahami ensensi dari class. Ini
seperti halnya mengatakan : ubah pola pikirmu menjadi ikan, terus diterjunin ke laut.

1.1.1. Diciptakanlah Class

Somehow class itu lahir dari pemikiran bahwa global variable itu perlu. Ironisnya di dunia OOP, fitur
global variable malah semakin dipandang sebagai dosa yang lebih berdosa lagi

Dari contoh di atas, kita lihat bahwa global variable tetap perlu untuk variable yang sifatnya system-
wide. Akan tetapi bagaimana kalau kita membutuhkan variable yang sifatnya tidak terlalu global sampai
dengan system wide, tapi juga bukan local variable yang dibutuhkan hanya oleh satu fungsi, melainkan
variable-variable ini dibutuhkan oleh sekumpulan fungsi. UNTUK MEMENUHI KEINGINAN INI,
DICIPTAKANLAH CLASS.

<Eiiitt, nanti dulu mas, inikan modul, bukan class? Sabar mas, kita pake konsep OOP terkini aja dimana
modul dianggap sebagai class yang instance-nya cuman satu. Abis itu baru kita masuk ke class yang
lebih umum.>

Misalnya klo di aplikasi kita mempunyai sebuah window dimana hasil dari setiap output kita harus
ditampilkan di dalam window tersebut.
1.1.1.1. Si Local Ternyata Adalah Global Berbulu Domba

Tanpa class, kita hanya punya dua pilihan, menggunakan local variable atau menggunakan global
variable.

Klo semua variable dijadikan local variable, maka misalnya window tersebut mempunyai atribut xLoc,
yLoc, Panjang, Lebar. Setiap kali kita mau menulis “Hello World!”, syntaxnya menjadi kira-kira :
print(xLoc, yLoc, Panjang, Lebar, “Hello World!”).

Kerepotan pertama sudah dijelaskan di atas, bagaimana klo si window tersebut mempunyai property
baru, berarti semua fungsi di aplikasi kita yang memanggil window tersebut harus diubah.

Dan ada satu lagi yang bahaya yaitu : perhatikan bahwa variable xLoc dan kawan-kawannya harus
dimaintain oleh pemanggil, pemanggilnya pemanggil, pemanggilnya pemanggilnya pemanggil, dan
seterusnya. Sepertinya bukan global variable, tapi efeknya sama seperti global variable. Misalnya di
salah satu pemanggil-pemanggil tersebut salah menimpa value salah satu dari xLoc dkk. Efeknya akan
terasa oleh yang dipanggil oleh si salah, yang dipanggil oleh yang dipanggil oleh si salah, dan seterusnya.
Bukankah ini efek yang mirip dengan variable global, dan dengan bonus : repot ngetik, repot copy-paste
klo atributnya bertambah. Inilah Global berbulu Domba (Local).

1.1.1.2. Solusi : Class

Jadi solusi yang tinggal adalah menggunakan global variable. Kalau window tersebut adalah satu-satunya
code dari aplikasi kita yang memerlukan variable global, fine, tetapi bagaimana jika kita juga punya
mouse. Berarti atribut dari mouse harus dibuat global juga. Nah ini mulai bahaya, karena code si window
bisa salah mengakses variable globalnya si mouse, dan sebaliknya. Ini bahaya karena mencari kesalahan
seperti ini, bisa seperti mencari kutu, bisa berjam-jam, dan berhari-hari.

Dengan diciptakan class. Masalah ini solve. Window kita jadikan class yang artinya semua variable
window tetap global tetapi hanya untuk semua fungsi yang berada di class window tersebut. Dan semua
variable mouse tetap global, tetapi hanya untuk semua fungsi yang berada di class mouse tersebut.

Perhatikan pola pikirnya adalah bukan berangkat dari class. Tetapi dari masalah coding kita. Jadi kita
mengerti “mengapa” kita memakai class, dan tentu saja akan mengerti “mengapa” kita tidak harus
selalu pakai class.

1.1.2. Diciptakanlah Object

Kalau window hanya satu, dengan class yang hanya mempunyai fitur untuk membuat variable 1/2 global
dan 1/2 local, problem solved. Tetapi gimana kalau aplikasi kita mempunyai lebih dari satu window.
Apakah kita harus copy-paste class window kita dan diganti nama jadi class window_juga, yang hanya
beda nama class, isinya totally sama persis. Bagaimana klo ternyata class window ada bug? Harus kita
betulkan, kemudian kita copy-paste ke semua class window_juga, window_juga_lho, window_lage_lage,
window_asli, dan klo ada 100 window gimana? Apa gak gompyor?

Oleh karena itulah diciptakan fitur object. Jadi daripada copy-paste, kita cukup bikin satu class window.
Kemudian class window ini istilahnya harus di-instantiate sebelum digunakan. Untuk instantiate kita
cukup gunakan syntax “window wnd = new window()”. Selanjutnya kita mengakses fungsi print di
window dengan syntax “wnd.print(“Hello World!”). Klo butuh satu window lagi kita tinggal pake syntax
“window wnd_juga = new window()”. Dan seterusnya. Sehingga klo class window ada bug, cukup
dibetulkan, tanpa perlu copy-paste, semuanya 100 window, bahkan klo ada ribuan window, juga
langsung beres.

Inilah object.

Lagi, perhatikan pola pikir yang berangkat dari masalah coding, dan fitur object adalah solusinya.
Bukan sebaliknya.

1.1.3. Diciptakanlah Implementation Inheritance

Ada banyak macam inherintance : untuk artikel ini kita bahas yang implementation inheritance saja.

Kalau window kita mau bisa ditampilkan di graphic card Asus dan graphic card NVIDIA, apakah kita harus
membuat dua class window untuk masing-masing graphic card? Bisa saja, tetapi terlalu banyak code
yang diduplikasi. Klo ada bug, apakah kita harus betulkan di satu class, kemudian copy-paste ke class
yang lain? Dan copy-paste ini sedikit lebih rumit karena ada bagian-bagian code yang memang berbeda,
yang tentu saja tidak boleh ke-paste.

Okay klo begitu akan baik klo code yang spesifik Asus dan spesifik NVIDIA dipisahkan. Dengan alasan
yang seperti di atas, mau pakai 1/2 global dan 1/2 local, dibuatlah class Asus dan NVIDIA. Tapi eit nanti
dulu, klo hanya seperti ini, tetap aja itu adalah dua class yang berbeda, yang akhirnya kita juga akan
punya dua class window untuk masing-masing class Asus dan NVIDIA.

Dari sinilah diciptakan implementation inheritance. Kita buat class kosong graphic card. Kosong itu
maksudnya kita cukup menyebutkan nama-nama fungsi. Nama-nama fungsi ini yang nanti di-refer / di-
call oleh class window kita. Sehingga kita tetap punya satu class window. Jadi tidak perlu lagi copy-paste
yang repot. Kemudian kita buat class Asus, yang istilahnya diturunkan dari class graphic card. Bahasanya
“seram”, “baru”, “cool”, “modern”, tetapi artinya gampang sekali, kita mengisi isi dari fungsi-fungsi yang
kosong tersebut. Jadi class window tetap satu saja. Punya satu class kosong untuk keperluan coding di
class window. Kemudian dua class Asus dan NVIDIA yang memang dua graphic card yang berbeda
sehingga wajar mempunya dua class (dua code = nambah kerjaan). Inilah yang dimaksud dengan
callback-reusable. Code yang manggil hanya satu (window), code yang dipanggilnya yang bisa banyak
(Asus dan NVIDIA).

Perhatikan pola pikirnya : dari problem coding, diberi solusi implementation inheritance, kemudian
dijulikin “re-usable”. Dengan demikian baru kita bisa mengerti “mengapa” kita menggunakan
inheritance. Dan “mengapa” kita tidak perlu inherintance. Jangan mau disuruh mikir seperti ikan terus
diceburin ke laut.

1.1.3 Apakah OOP dan Prosedural Berbeda

Jelas tidak. OOP melengkapi teknik programming prosedural, sebagai lanjutan dari penyempurnaan
teknik programming, mulai dari jamannya Von Newman 100 tahun yang lalu. Tidak ada yang mistis
mengenai itu. Semuanya berangkat dari pemikiran yang sederhana, yang saya yakin masih dalam batas-
batas kemampuan manusia normal. Hanya memerlukan pola pikir yang tepat.

Dan itu hanya satu macam dari sekian ratus teknik programming yang ada. Perkara itu memang popular
karena solving lebih banyak kasus dibandingkan teknik yang lain, ok saja. Tetapi jangan terjebak ke pola
pikir “ooo, semuanya harus object”. Programming adalah dunia yang sangat kreatif. Hanya dengan open
mind, kita bahkan mungkin menciptakan sebuah metodologi programming sebagai penyempurnaan dari
OOP. Seperti halnya OOP menyempurnakan prosedural. Make the tool works for you. Do not work for
tool.

Jangan pernah takut bertemu dengan what-so-called pakar object oriented, pakar design pattern, blah,
blah. Tanyakan saja bagaimana bentuk code akhirnya, klo sama-sama saja, klo jawabnya ah-eh-ah-eh,
forget it. Ingat tujuan kita adalah menulis instruksi dengan lebih efisien, yang klo perlu sambil tidur dah.
Teori boleh segunung, tetapi klo code-nya sama saja, gimana bisa lebih efisien? Bahkan itu menunjukkan
dia sama sekali tidak pernah memahami esensi yang paling basic dari “mengapa” kita coding. Boleh
dipastikan itu adalah pakar omong-kosong.