Kalau seorang negarawan di negeri ini mengenalkan Empat Pilar Kebangsaan, maka Pemrograman Berorientasi Object (PBO) juga mempunyai Empat Pilar yang menjadi karakteristiknya. Di bawah ini coba saya uraikan dengan bahasa mudah yang semoga sampeyan semua sedikit lebih “dong” dalam belajar PBO. Kalau beberapa point nantinya keliru ya mohon dimaafkan dan monggo dikoreksi 🙂

Biasanya, dalam mengenal PBO, kita akan dihadapkan pada 3 (tiga) pilar utama yakni Encapsulation, Polymorphism dan Inheritance. Namun rugi rasanya kalo sampeyan sudah mampir kesini dan tidak menemukan sesuatu yang beda. Ketiga pilar diatas benar, namun menurut saya akan lebih tepat lagi kalau sudah menginjak ke tingkat coding. Karena materi ini untuk melanjutkan materi sebelumnya yakni Memahami Perbedaan Object dan Class Dalam Pemrograman Berorientasi Object maka sebelum oprek coding, empat pilar ini sengaja saya tulis disini biar sampeyan tahu bagian paling mendasar terlebih dahulu.

Artikel ini ditujukan untuk yang belum mengerti blass soal PBO, soal coding dll. Jadi untuk yang benar-benar baru dalam mengenal PBO. Untuk yang sudah Advanced, sekali lagi jangan ditertawakan, dan saya sangat berterima kasih sekali sekiranya sudi turut membagi ilmunya dengan berdiskusi di kolom komentar.

Abstraction

Cukup sulit memang untuk menjelaskan apa itu Abstraction. Abstraction merupakan karakteristik dasar dari sebuah object yang membuatnya berbeda dengan object (benda) yang lain. Namun demikian, abstraction juga bergantung pada perspective. Artinya beberapa hal penting yang mungkin penting dari sebuah konteks, akan menjadi tidak penting jika dalam konteks yang lainnya.

Misalnya nih bro, katakanlah sebuah object Product. Ketika dalam sistem Shipping, maka attribut Size dan Weight itu penting, namun attribut Warna tidaklah penting. Tapi ketika object Product ini digunakan dalam Point Of Sales, maka attribut Warna & Harga Satuan menjadi hal yang penting disitu. Atau dalam contoh lain, seorang Sopir tidak perlu tahu bagimana mesin mobil bekerja, bagaimana timing pengapiannya, bagaimana setting ECU nya, yang penting dia bisa injak gas dan mobil jalan… selesai. Tapi lain halnya jika mobil itu di tangan seorang mekanik/bengkel, dimana object-object yang tadi tidak berguna untuk Sopir, namun jadi sangat penting bagi seorang mekanik/bengkel.

Artinya, dalam membangun aplikasi PBO, maka kemampuan menggabungkan konsep abstraction ini penting, karena biasanya kita hanya terpaku pada bagian tertentu dari property sebuah object tertentu tanpa mampu memilah-milah properties mana yang digunakan untuk konteks tertentu dan mana yang tidak perlu untuk digunakan.

Mumet kan sampeyan ? hehe… podho…

Encapsulation

Bicara soal capsule, berarti terbungkus. Yakni menyembunyikan informasi / bagaimana sesuatu itu dilakukan. Misalnya, ketika Sopir menginjak REM, maka dia tidak perlu bagaimana cara kerja rem itu, bagaimana cara kerja kaliper dalam menjepit disk brake dan lain sebagainya. Tapi yang jelas dia harus tahu, kalau mau memperlambat mobil, maka injak rem.

Hal ini yang kadang membuat bingung. Beberapa programmer awal yang sudah terbiasa dengan struktural pasti apda protes. Kira-kira begini

“Lha kan kita harus tahu secara detail apa yang dilakukan, mosok disembunyikan ? “

Kadang saya ga ngeh juga, soalnya yang berkomentar tersebut di atas mengartikan bahwa dia sebagai programmer ga berhak tahu apa yang terbungkus dalam object. Padahal maksudnya adalah ketika memprogram dalam PBO, sebuah object lah yang dibatasi, bukan programmer nya. Misalkan klo dalam dunia nyata, mau ngirim paket via ekspedisi. Kita tinggal ke agen, serahin barang, bayar biaya, dan berikutnya tinggal nunggu barang sampai ke tujuan tanpa perlu tahu bagaimana barang dikirim bukan ? mau pake bis, pesawat, dianter kurir pake motor, ya terserah perusahaan ekspedisi. Jadi kita sebagai object pengirim tidak perlu tahu (tidak penting untuk tahu) bagaimana ekspedisi mengirim barang. Yang penting kiriman kita sampai.

Di dalam program aplikasi, encapsulation ini menghilangkan ketergantungan terhadap implementasi. Maksudnya adalah, setiap object mempunyai implementasi sendiri yang terpisah, sehingga akan lebih mudah memaintainnya. Disinilah perbedaannya dengan pemrogram tersetuktur yang cenderung orientasinya adalah terhadap urutan sebuah proses cara pemecahan masalah, sedangkan dalam PBO adalah object apa yang dapat memecahkan masalah tersebut.

Tambah mumet kan… ?

Modularity

Dengan PBO, maka sebuah sistem yang komplek dibangun dari beberapa object-object kecil yang sederhana. Object-object ini dibagun satu persatu secara independen, namun interaksi antar object ini tetap harus diperhatikan.

Tambah bingung ? Program kok dipecah-pecah ? Apa ga rumit ? Gimana menyatukannya ?

Memahami sebuah sistem Point Of Sales mungkin akan berat. Namun jika kita bagi menjadi bagian-bagian kecil semisal Inventory, Penjualan, Pembelian, Accounting dan bagian lainnya, maka akan lebih mudah, seberapapun kompleksnya. Dan mungkin object-object itu akan dipecah menjadi beberapa bagian lebih kecil lagi dan seterusnya.

Atau dalam kasus lainnya, bekerja secara tim. Dimana Tim A mengerjakan Modul Pembelian, Tim B mengejakan Modul Penjualan, Tim C mengerjakan Modul Inventory. Bayangkan bila ketiga tim bekerja bersama-sama kalau aplikasi tidak dipecah, boro-boro dipecah, mungkin Versioning Control (saya bahas tool untuk versioning kontrol ini lain kali) aja malah ga ngerti atau malah belum pernah denger sama sekali. Jadinya malah tumpang tindih dan ga jelas siapa mengerjakan apa, semua semrawut jadi satu.

Hirarki

Setelah Abstraction, Encapsulation dan memecah menjadi bagian-bagian kecil dengan Modularity, maka akan tercipta sebuah pola hirarki. Sebuah program yang kompleks jika tidak bisa diketahui bagaimana pola hirarki nya, ya pasti susah dipahami apalagi mau dibuat. Hirarki ini juga bisa dibilang sebagai hasil dari proses pengurutan dan penataan dari satu atau beberapa Abstraction hingga hasilnya menjadi sebuah pohon hirarki.

Dengan pendekatan PBO, maka mendesign sebuah program justru jauh lebih mudah daripada struktural. Karena lebih jelas dan lebih terstruktur dengan baik, dimana sebelumnya terstruktuk berdasarkan urutan cara kerjanya, dengan PBO tersetruktur berdasarkan Object-nya.

Aggregation

Lho katanya empat pilar ? kok nambah 1 (satu) lagi… nah itulah seni nya mas bro dan mbak sis sekalian. Bukankah tadi di awal artikel, abstraction itu adalah sesuatu yang sifatnya konseptual tergantung perpective penggunaanya. hehehe.

Aggregation dapat diartikan sebagai sebuah object yang terdiri dari beberapa object lainnya yang bekerja bersama, seiiring sejalan dan seperjuangan… 🙂 halah ….. Misalnya, Object Mobil kan terdiri dari Object Roda, Object Chasis, Object Mesin dll… Object Roda terdiri dari Object Velg, Object Ban Dalam, Object Ban Luar dan seterusnya. Itulah Aggregation.

Demikian mas bro dan mbak sis sekalian, biar semakin mumet pokoknya 🙂 Paling asyik kalo konsep seperti ini bisa saya jelaskan dengan lisan secara langsung, coz tulis menulis seperti ini buat saya jauh lebih sulit dari coding.. 😀