Pemrograman yang hanya pemrograman

[nelvin]

Tweet

Selama ini kita sering dijejalkan dengan berbagai teori pemrograman. Di sini marilah kita bersama2 diskusi mengenai esensi dari teori tersebut. Apakah betul bermanfaat, apakah hanya teori yang terlihat indah belaka. Mari kita selalu bertanya mengenai "why"nya, dan berdiskusi dengan asyik.

Salam,
Nelvin

Localization adalah Esensi dari Object Oriented Programming

Begitu banyak buku mengenai Object Oriented Programming(OOP) telah ditulis. Akan tetapi hingga saat ini, pemahaman mengenai OOP dirasamasih kurang. Begitu banyak code OOP yang saya lihat, tetapi yang digunakanhanyalah syntax nya saja. Sedangkan esensi terpenting dari OOP nya sendirijustru tidak ada, tidak disadari, atau tidak dimengerti. Sehingga code nyatetap saja penuh dengan bug yang tidak dengan mudah bisa dicari untuk di-fix.(As you know : creating bugs is human nature, but creating bugs that cannot befixed easily is a showcase of lack of skill.)



Artikel ini mengajak para pembaca untuk kembali ke pemahamanmengenai OOP dari esensi paling dasar, tanpa terlebih dahulu dipengaruhi olehbanyak distraction / dengungan tidak jelas yang justru membuat kabur esensipaling dasar tersebut. Karena hanya dengan pemahaman terhadap esensi palingdasar inilah, baru akan terbuka kunci untuk menerapkan semua teknik OOP turunannya dengan tepat.



Mengapa OOP gagal diimplementasikan

Mari kita mulai dengan pertanyaan mengapa OOP setelah sekianpuluh tahun, masih juga gagal diimplementasikan. Berikut adalah pendapat saya.(Apakah para pembaca mempunyai jawaban lain – silahkan share di thread ini.)

• Kebanyakan pelajaran mengenai OOP selalu dimulai denganpembahasan mengenai SYNTAX bahasa OOP, yang memang paling popular yaitu :Encapsulation, Inheritance, dan Polymorphism. Padahal ketiga hal ini merupakanimplikasi dari teknik OOP, bukan esensi dari OOP, atau the reason behind atau “why”teknik OOP sangat powerful. Tanpa mengerti “why” nya, kita tidak akan pernahtahu dengan tepat kapan kapan ketiga hal tersebut seharusnya digunakan. Danbahkan lebih parah lagi karena banyak esensi dari OOP yang tidak dicover olehketiga syntax tersebut, malah tidak dipergunakan. Jadi walaupun telah menggunakanOOP, coding nya tidak jauh berbeda dengan cara coding 30 tahun yang lalu.
  
  
  
  
• Contoh yang digunakan hampir selalu menggunakan contohparadigma keluarga buah-buahan, atau kendaraan, atau jenis-jenis binatang, tanpamenunjukkan secara gamblang kenapa sebuah teknik sangat powerful. Maksud sayagamblang adalah seharusnya ditunjukkan dengan sebuah “technicaljustification” sehingga tidak terbantahkan. Technical justification yangdimaksud adalah sedikitnya harus mempunyai satu dari dua unsur berikut. Unsurpertama adalah : dinyatakan dengan sebuah angka seperti halnya membuktikansebuah persamaan matematika. Jadi BUKAN dengan istilah-istilah abstract seperti: “lebih mudah dicari bug nya”. Tetapi tunjukkan dengan pernyataan seperti :dengan cara ini jika ada bug kita hanya cukup mencari di bug di satu file,sedangkan dengan cara yang lain kita harus search bug tersebut di tiga ribufile. Unsur kedua adalah jika somehow tidak bisa dinyatakan dengan angka, harusada sebuah postulat bersama, atau sebuah definisi bersama, yang sangatsederhana sehingga dengan mudah bisa dijadikan dasar untuk membuktikan sebuah codingstyle adalah lebih baik – tidak terbantahkan. Simply kita berbicara programmingseperti halnya kita berbicara persamaan matematika yang tidak terbantahkan.
  
  

Technical justification

Hanya jika kita bisa lepas dari kedua kesalahan tersebut,barulah kita bisa membangun skill OOP kita. Skill hanya bisa dibangun dengandilatih. Melatih hal yang salah, hanya membuat kesalahan kita menjadi perfect.Technical justification yang gamblang dan terang benderang, dan dalam banyakcase dinyatakan dalam angka yang terang benderang, akan menjamin bahwa kitatidak berlatih hal yang salah.



Errhh... berlatih?? Ya seharusnya jelas bukan bahwa skillharus dilatih. Akan tetapi yang terjadi di dunia programming (dan untung nyajuga terjadi di dunia martial art), adalah justru sebaliknya. Orang cenderungmengumpulkan teknik, bukan melatih teknik tersebut.



Berbeda dengan pandangan kebanyakan pandangan programmeryang kurang berpengalaman, atau para teoritis / pengamat pemrograman yang hanyapernah juggling beberapa baris code untuk contoh artikel, tetapi tidak pernahberlatih pemrograman secara real, selalu beranggapan bahwa programming bisadikonseptualkan sejak awal. Well konseptor yang paling berpengalaman di duniapun paling banter hanya sanggup mencapai 10% dari aplikasi. Sisanya baru bisa ditemukanpada saat programming dilakukan. Tanpa pernah berlatih, kita tidak akanmempunyai kepekaan terhadap pola-pola code yang dihasilkan, yang sepintas laluhanya seperti random, sehingga miss opportunity untuk menerapkan konsep yangbagus. Bahkan konsep yang paling sederhana / esensi seperti localization punbisa luput dari pandangan (apalagi konsep turunan dari localization yang lebihkompleks seperti object oriented). Karena itu tidak ada cara untuk meningkatkanskill programming adalah dengan mengenali banyak, sebanyak-banyaknya aplikasi darisebuah teknis, dan terus berlatih seperti itu, sampai mempunyai kepekaanterhadap pola-pola yang ditemukan pada saat programming. Berlatih sampaidaya reflex nya terbentuk.



Karena itu pula saya sangat against kebiasaan yangmemberikan contoh pengaplikasian dengan konsep abstrak yang lain. Ini hanyamembuat orang tenggelam dalam lautan teknik dan kehilangan awareness terhadapesensi dari teknik. Contoh aplikasi haruslah dalam bentuk seperti persamaanmatematika, yang dalam kasus ini harus dengan gampang ditunjukkan dengan codesecara gamblang, yang kemudian bisa dihitung 1-2-3 dengan mudah... that iscontoh yang memenuhi kriteria technical justification.



Syntax OOP bukanlah esensi dari OOP

Salah satu tujuan paling hakiki dari semua teknikpemrograman adalah bagaimana membuat program yang berjalan baik dengan waktuyang secepat-cepatnya. Atau dengan kata lain adalah produktifitas. Peningkatanproduktifitas paling significant adalah pada saat pertama kali diciptakanbahasa tingkat tinggi. Dari tadinya kita harus mengetik berbaris-baris syntaxbahasa assembly / mesin, atau bahkan puluhan syntax, cukup hanya digantikanhanya dengan satu-dua syntax bahasa tingkat tinggi. Ini jelas peningkatan produktifitas,karena jelas technical justification nya. Yaitu : misalnya 5 syntax menjadi 1syntax, jelas terjadi peningkatan produktifitas sebesar 5 kali. (Perhatikan: ada angka yang menjadi technical justification.)



Bahasa tingkat tinggi berevolusi terus sampai yang palingsignficant adalah dengan diciptakannya bahasa tingkat tinggi yang menerapkankonsep prosedural. Dan kita tahu setelah itu popular bahasa tingkat tinggi yangsyntax-syntax nya dapat digunakan untuk menerapkan konsep object orienteddengan nyaman, yang disebut bahasa pemrograman object oriented.



Masalah nya adalah banyak programmer yang terpaku padasyntax dari object oriented, sedangkan produktifitas yang didapat dari bahasaobject oriented JELAS bukanlah dari perubahan syntax prosedural menjadi objectoriented. Coba perhatikan dua syntax ini, dimana yg pertama merupakan syntaxprosedural, sedangkan yang kedua merupakan object oriented:

• ResizeWindow(chartObject, …)
  
  
• chartObject.ResizeWindow(…)
  
  

Kedua syntax tersebut mempunyai jumlah karakter yang hampirsama. Sehingga jelas tidak ada peningkatan produktifitas dalam hal syntaxseperti halnya perubahan dari bahasa assembly ke bahasa tingkat tinggi. Tentumenjadi jelas jika dikatakan kegunaan dari teknik / bahasa object orientedbukanlah sekedar perubahan syntax seperti di atas. Padahal inilah jawaban yangselalu saya dapatkan, mungkin 9 dari 10 jawaban, setiap kali saya bertanya keseorang programmer mengapa object-oriented sangat powerful. Tidak heran jikaakhirnya pemanfaatan object oriented tidak terlihat benefit nya jika digunakanoleh programmer dengan pemahaman yang serendah itu.



Beberapa orang akan beragumen : dengan cara object oriented,syntax nya menjadi lebih jelas. Saya akan challenge dengan pertanyaan “berapa banyaklebih jelas??”. Adakah kadar mengenai “lebih jelas” dari case di atas yang bisadinyatakan dalam angka?? Bisakah ditunjukkan claim lebih jelas itu dengan angkaseperti 10% lebih jelas atau 3000% lebih jelas?? Jika tidak bisa, alasan iniadalah alasan kabur yang dengan gampang dibantahkan, karena “lebih jelas” disini hanya sekedar masalah preferensi. Dengan konsep technical justificationdimana selalu harus ada angka atau sebuah postulat sederhana, argumen di atasyang sekedar berisi claim “lebih jelas” dengan sendirinya tidak berharga. Dansaya pribadi, diharapkan juga para pembaca, tidak mau menghabiskan waktu untuk berdebatmengenai hal-hal mengambang seperti ini. Lets kita fokuskan waktu yang sangatberharga kepada hal-hal yang lebih jelas seperti statement “peningkatanproduktifitas 100 kali”. Sangat gamblang dan terang benderang karena ada angka“100” tersebut – atau whatever angka. Bahkan angka yang “hanya” “dua kali” punmasih jauh jauh lebih berharga dibandingkan argumen yang tidak mempunya angkaatau technical justification.



Jika pembaca masih setuju dengan saya, mari kita lanjut.



”WHY” OOP

Setelah kita membahas mengapa semua hal yang popular di atasbukanlah esensi dari OOP, diharapkan semua pemikiran yang salah seperti di atassudah dibuang jauh-jauh dari kepala kita, dan kita ready dengan lembaran baru.



Bahasa tingkat tinggi memberikan produktifitas denganmagnitude yang luar biasa. Seiring dengan meningkatnya produktitas, jumlah codeyang ditulispun kembali menjadi luar biasa. Dan ini menimbulkan challenge baru.Kenapa? Karena simply otak manusia terbatas, sehingga tidak mungkin dalam satuwaktu seorang manusia normal sanggup mengatasi kompleksitas dari jumlah code yangsangat banyak tersebut. Cara mengatasi kompleksitas tersebut tentu saja adalahdengan membagi program yang berukuran super besar tersebut menjadibagian-bagian yang lebih kecil yang masih sanggup dihandle oleh otak manusia.



Teknik yang memecah-belah kompleksitas menjadi sub-bagianyang bisa dihandle oleh otak manusia,adalah teknik umum yang digunakan diberbagai bidang apapun. Khusus utk bidang programming ini, saya sebut sebagai LOCALIZATION.Lhoooww??? Kok bukan object-oriented??? Object oriented memang mempunyai fituryang lebih banyak dibandingkan hal yang lain, sehingga by-default object orientedmenjadi lebih popular. Tetapi perlu diingat bahwa object oriented ada karena kebutuhanmelakukan localization. Sehingga tanpa memahami localization terlebih dahulu,tentu tidak akan dapat menerapkan object oriented dengan maksimal.



Encapsulation, inheritance, dan polymorphism, merupakanpengembangan dari teknik-teknik pemrograman yang sudah dimulai sejak ilmu programmingtercipta, yang disempurnakan dengan bahasa tingkat tinggi, disempurnakan denganprosedural, hingga yang sekarang disebut object oriented, tetapi dasar konsepnya tidak pernah berubah yaitu untuk menerapkan localization. Sayang dengansemakin banyaknya teknik, kita cenderung melupakan esensi “why” teknik tersebutdiciptakan, sehingga pengaplikasian nya menjadi salah dan benefit nya menjadihilang. Oleh karena itu, kita akan membahas localization terlebih dahulu,sebelum akhirnya kita akan kembali ke pembahasan object oriented tentu saja.

[nelvin]

Tweet

Teknik-teknik localization

Karena OOP merupakan kumpulan teknik untuk menerapkan localization, yaitu membagi-bagi masalah menjadi seukuran yang bisa dihandle oleh otak kita, secara natural jika kita melakukan pengamatan terhadap semua syntax OOP, ini tidak lain adalah diciptakan untuk membantu pengaplikasian localization. Oleh karena itu, sebelum kita berlatih OOP secara khusus, kita harus berlatih localization yang merupakan bentuk yang paling esensi dari pengaplikasian OOP. Untuk berlatih kita harus dimulai dari pondasi yang paling dasar. Pondasi paling dasar ini dimulai dengan mengenali beberapa teknik localization, yang kemudian untuk dilatih sehingga timbul daya reflex kita mengenali pola-pola coding yang terbentuk, dan menerapkan teknik localization.



L1 : Pecahkan kompleksitas

Jika kita mempunyai code dengan jumlah 1000 baris code tentu sangatlah kompleks. Bayangkan jika kita pecah menjadi 10 bagian, dengan masing-masing bagian berisi 100 baris code, dan setiap 100 baris code tersebut kita pecah lagi menjadi 10 bagian, sehingga masing-masing berisi 10 baris code. Dengan demikian akan menjadi sangat simple, karena dalam satu waktu kita hanya perlu memfokuskan otak kita hanya terhadap 10 baris code. Ini bentuk localization pertama, dimana otak di-localize atau di-fokuskan hanya untuk 10 baris code.



Technical justification : dari 1000 bari code diubah menjadi 10 baris of code, berarti 100 kali lebih sederhana. Ini jelas something very very significant.



L2 : Yang saling terkait dikumpulkan menjadi satu

Pemecahan di atas tentu saja bukan sembarang pemecahan. Memecahkan sebuah hal yang saling terkait justru menambah pekerjaan yang tidak perlu. Bagaimana pun tujuan pemecahan adalah supaya menjadi lebih sederhana, tentu saja pemecahan tersebut harus menghasilkan sebuah bentuk yang betul-betul independen. Jika nilai variabel A tergantung variabel B, dan variabel A ditempatkan di tempat yang terpisah dengan B, maka itu hanya bentuk lain dari peningkatan kompleksitas, yang berlawanan dengan konsep L1. Kenapa? Karena pada saat kita memanipulasi variabel B, kita harus mengetahui ada variabel A, yang tempat nya entah berada dimana, yang juga harus diperhatikan. Jelas ini adalah sebuah kompleksitas yang di luar jangkauan otak kita.



Technical justification : jika variabel A dan B misalnya berada dalam satu class, opportunity kita untuk mengenali bahwa A tergantung B akan jauh lebih besar, dibandingkan jika variabel A ditempatkan di file code yang berbeda. Karena jika sebuah aplikasi mempunyai 1000 file, maka kita harus memahami seluruh code yang berada 1000 file tersebut. Jelas dalam kasus ini kompleksitas nya adalah paling sedikit 1 berbanding 1000.



L3 : Yang berpola sama dilocalize menjadi satu

Ini nama lain nya adalah membuang semua redudancy. Jika Anda memiliki urutan algoritma yang selalu sama seperti setiap kali call fungsi A dilanjutkan dengan call fungsi B, fungsi A dan B harus digabungkan menjadi fungsi C dimana di dalam nya berisi call terhadap fungsi A yang dilanjutkan dengan call fungsi B. Kita memang dengan gampang menciptakan sebuah fungsi umum yang sering digunakan oleh di banyak bagian dari aplikasi. Misalnya fungsi seperti DisplayText secara natural gampang diindentifikasi akan digunakan oleh banyak bagian dari aplikasi. Tetapi yang selalu miss adalah opportunity untuk mengidentifikasi urutan redudancy call seperti case fungsi A dan B di atas, yang pada awalnya terlihat seperti random.



Technical justification : fungsi C tidak akan pernah lupa bahwa setiap call fungsi A akan dilanjutkan dengan call terhadap fungsi B, tetapi manusia normal pasti akan mempunyai kemungkinan lupa untuk call fungsi B. Jelas bedanya : yang pertama chance nya 0%, yang sebaliknya chance nya selalu lebih besar dari 0%.



L4 : Jangan publish sesuatu lebih dari yang diperlukan

Jika kita mempunyai variabel A yang tergantung dengan variabel B, seperti misalnya A = B + 3. Maka variabel A hanya bisa dipublish sebagai read only variabel. Ini menjamin variable-variable yang sudah kita kumpulkan jadi satu dengan teknik L3 di atas, tidak diutak-atik oleh bagian program yang lain. Dengan otak yang terbatas kita tidak mungkin setiap kali ingat bahwa sebuah variable tidak boleh diakses sembarangan. Hmm, seperti halnya “lokalisasi” yang baik untuk merapihkan W/PTS supaya tidak merusak masyarakat, ternyata baik juga untuk merapihkan code-code yang tuna-susila.



Technical justification : jika suatu hari variabel A berisi angka yang salah, kita bisa dengan yakin bahwa bug pasti hanya terjadi di scope pemilik dari A, misalnya class yang berisi variabel A tersebut. Dibandingkan jika harus keliling mencari code misalnya di seluruh 3000 file yang merupakan bagian dari aplikasi lengkap.



Apa bedanya???

Ah kalau sekadar aturan-aturan seperti di atas, apa bedanya teknik-teknik localization tersebut dengan teknik-teknik yang biasa dijumpai di buku-buku object oriented?? Beda banget. Penekanan dari semua teknik localization di atas adalah langsung applicable untuk dilatih.



Perhatikan semuanya berisi aturan terang benderang tentang apa yang harus dilakukan untuk setiap case, exactly step by step, di level code by code. Bandingkan misalnya dengan konsep encapsulation dengan teknik L3. Encapsulation mengajarkan bahwa kita harus menemukan kesamaan di problem / modeling / solution domain untuk kemudian diencapsulate. Perhatikan encapsulation tidak mensuggest coding dimulai dari code tetapi dari high level point of view yang begitu abstrak (problem / modeling / solution). Bagaimana membandingkan abstraction yang satu lebih baik daripada abstraction yang lain. Dengan membandingkan code nya baris demi baris. Bagaimana membandingkan nya supaya kita tidak salah pilih? Supaya tidak terjebak di dalam debat kusir?? Dengan teknik L3 tersebut yang mempunyai technical justification jelas. Hanya programmer yang memang sudah terlatih, dan terlatih dengan cara yang valid, yang mempunyai probabilitas lebih besar untuk menebak abstraction yang tepat. Dan bahkan programmer yang paling terbaik pun, paling banter hanya mampu menebak 10% dari konsep abstraction yang akhirnya terbukti paling tepat, yaitu abstraction final yang digunakan pada saat aplikasi selesai didevelop.



Jadi encapsulation adalah pendekatan top-down, sedangkan localization adalah pendekatan bottom-up, yang memang pada akhirnya akan bermuara ke encapsulation. Tetapi jika bahkan programmer terbaikpun hanya sanggup menebak dengan ketepatan 10%, mengapa buang waktu dengan mencari-cari encapsulation / abstraction terlalu dini?? Dengan localization, teknik langsung diapply di level code by code. Bottom-up sehingga terbentuk abstraction dan encapsulation secara natural terbentuk dengan solid. Simple. Jelas. Sehingga programmer pemulapun sudah bisa langsung menerapkan teknik localization di first code yang ditulisnya dengan akurasi yang sangat tinggi.



Inilah kenapa localization saya sebut merupakan esensi dari object oriented.



Selanjutnya saya akan memperlihatkan bahwa object oriented hanya merupakan teknik untuk menerapkan salah satu teknik localization di atas.



Object oriented hanyalah penerapan dari localization

Saya tidak akan membahas satu per-satu teknik object oriented karena sudah ada ratusan ribu buku yang membahas ini. Saya hanya menunjukkan satu teknik inheritance untuk menunjukkan korelasinya terhadap teknik localization. Jika Anda sudah mahir dengan localization, Anda dijamin akan dapat menemukan korelasi-korelasi yang lain sendiri.



Re-usable adalah kata yang selalu didengung-dengungkan oleh developer OOP. Sayangnya saya belum pernah menemukan satu developer-pun yang bisa menunjukkan ini dengan baik. Contoh yang selalu digunakan untuk menunjukkan re-usable adalah ke-tiga-pilar-omong-kosong itu.



Re-usable itu sudah ada, bahkan di bahasa assembly yang paling primitif-pun sudah ada. Kalau Anda punya fungsi, dan fungsi itu bisa digunakan oleh seluruh bagian dari code, ini adalah re-usable. Perkara fungsi itu letaknya ada di class, module, manifest yang berbeda (beda exe), dll, selama fungsi itu bisa kita akses, namanya adalah re-usable. Ok.



Jadi apa yang ditambahkan oleh OOP ke masalah re-usable ini? Inilah sifat khusus dari inherintance, baik implementation inheritance maupun interface inheritance, yang bermanfaat untuk meningkatkan re-usable dari code. Re-usable yang sudah sejak dulu tersedia adalah “calling re-usable”, yaitu banyak code memanggil sebuah code. Jika Anda mempunyai sebuah fungsi “CalculateBonus”, dan fungsi ini dipanggil dari modul Sales Order dan Delivery Order, ini adalah “calling re-usable”. Yang belum tersedia secara explisit di bahasa-bahasa non-OOP adalah“callback re-usable” (kecuali menggunakan pointer, tetapi pointer berpotensi menimbulkan masalah lain yang lebih serius). Jika Anda membuat aplikasi seperti Trilian Messenger, yaitu sebuah program chatting yang mempunyai fitur untuk chat dengan berbagai messenger lain seperti Yahoo! Messenger, MSN Messenger, Google Messenger, ICQ, dll, akan lebih convenience jika Anda menyediakan satu macam user interface untuk chatting yang bisa bekerja dengan semua messenger tersebut. Atau seperti Windows yang bisa mengakses berbagai macam hardware. Inilah problem yang solusi paling baiknya adalah menggunakan “callback re-usable’.



Keliatannya bedanya? Untuk “callback re-usable”, code pemanggilnya yang digunakan bersama-sama (untuk kasus “calling re-usable”, code yang dipanggil yang digunakan bersama-sama).



Apa hubungan nya dengan localization? Jelas ini adalah penerapan dari teknik L3 : Yang berpola sama dilocalize menjadi satu. Pola yang sama bisa terjadi di mana saja, caller dan callee. Begitu kita punya intention untuk menggabungkan pola yang sama ini, bahkan tanpa OOP pun kita akan menggunakan pointer. Jika languange nya tidak support pointer, kita akan menggunakan teknik array of function code. Jika array of function code tidak disupport, kita akan menggunakan teknik GOTO (GOTO??? YES GOTO!!!). Kebetulan OOP punya syntax inheritance yang lebih nyaman dari goto, teknik array of function code, maupun pointer. Thus kita pakailah itu OOP punya teknik.



Tanpa pemahaman terhadap teknik L3 yang sangat sederhana, well saya sering sekali melihat code yang sangat menggelikan. Semua class diturunkan dari satu base class. Atau setiap class selalu mengimplementasikan sebuah interface yang hampir sama ( ngapain repot-repot Booosss??? Buang aja tuh interface ).



Penutup

Penjelasan teknik-teknik localization di atas begitu sederhana, sehingga kita merasa ah begitu gitu saja. Tetapi coba Anda buka code Anda sendiri, dan Anda akan surprise, karena tanpa awareness yang dilatih terus menerus, akan ditemukan sekali banyak sekali code-code yang bertentangan dengan teknik localization yang terang benderang tersebut. Pengalaman code review yang saya lakukan menunjukkan hal ini. Bahkan saya hampir tidak melihat bedanya code yang dibuat oleh programmer yang sudah berpengalaman 10 tahun dan code yang dibuat oleh programmer yang baru hanya mempunyai pengalaman beberapa bulan. Sedih memang – tetapi itulah fakta lapangan. Di sinilah sekali lagi menunjukkan bahwa kemampuan programming hanya bisa didapat melalui latihan. Lebih baik mempunyai satu teknik / satu jurus, daripada memahami ratusan teknik / jurus –seperti para pengamat programming – tetapi tidak ada satupun yang menjadi daya reflex nya.



Jangan sampai kita terjebak menjadi pengamat programming, yang bahkan dirinya sendiri tidak sadar bahwa dirinya hanya pengamat. Merasa dirinya pakar – selalu memperkenalkan teknik-teknik baru yang membuat programmer lain merasa minder karena “kok rasanya tidak make sense”, tetapi karena para “pakar” tersebut mempunyai kemampuan pencitraan diri yang baik, sehingga justru programmer lain tersebut yang merasa dirinya pandir. Programmer pengamat yang membuat programmer berbakat justru merasa pandir. Ini adalah sebuah cacat yang saya sebut sebagai “NORMAK SYNDROME”. Jangan sampai ketularan!



NB : by the way bagaimana menghindari terjebak ke dalam arus Normak Syndrome tersebut? Untungnya gampang, tanyakan saja sudah berapa lama programming, dan sudah pernah membuat code berapa ratus ribu baris. Jika significant, than you listen to him/her. Remember : you wan’t be a fighter by just reading and talking. Just code it, and show your code blatlantly.





Happy programming!

[nelvin]

Tweet

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.

[The_Quantum]

Tweet

Begitu banyak buku mengenai Object Oriented Programming (OOP) telah ditulis. Akan tetapi hingga saat ini, pemahaman mengenai OOP dirasa masih kurang. Saya kira sebab-musabab-nya adalah terletak pada dua hal:

• Buku OOP selalu memulai pembahasannya dengan SYNTAX bahasa OOP, yang memang paling popular yaitu : Encapsulation, Inheritance, dan Polymorphism.
• Selalu mulai dengan contoh paradigma keluarga buah-buahan, atau kendaraan, atau jenis-jenis binatang, yang memang merupakan object di dunia nyata, tapi relevansinya dengan dunia programming, yg sangat virtual, yg penuh kreativitas dan khayalan, sangatlah jauh. Yang terbaik dari contoh ini adalah ya itu… untuk melatih menghafal syntax-syntax OOP di atas.

Saya setuju dengan pendapat ini. Banyak developer pemula termasuk para pengarang lokal dan tenaga pendidik yang hanya berteori mengenai OOP. Pemahaman mereka tentu akan berkembang seiring dengan karir mereka.

OOP memang bisa diterapkan pada bahasa apapun bergantung pada disiplin developer yang terlibat. Akan tetapi, penerapan seperti ini akan mempersulit maintenance dan lebih rentan terhadap bug karena developer harus serba waspada.

Mungkin ini dapat dibandingkan dengan dulu saat programmer membuat program langsung dari bahasa mesin. Saat compiler pertama kali diperkenalkan, mereka meragukan kemampuan bahasa mesin yang dihasilkannya. Apa mungkin bahasa mesin program yang dibuat dengan compiler Pascal atau C lebih baik dari yang dibuat langsung oleh programmer itu sendiri? Tentu saja tidak. Tapi lihat saat ini, hanya developer nekat saja yang masih membuat program dari bahasa mesin dan menghindari penggunaan compiler.
OOP mungkin akan mengubah hidup developer, seperti saat compiler pertama kali diperkenalkan.

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.

Di satu sisi, ini terasa tidak adil bagi programmer junior. Tapi ini jelas mempermudah pengembangan sistem. Kita akan dihadapkan dengan satu lagi lowongan baru bagi programmer, yaitu object engineer. Mereka bertugas membuat object dengan dokumentasi yang sangat jelas. Mereka menguji object mereka. Programmer kemudian memanfaatkan object buatan mereka untuk merancang perangkat lunak guna memecahkan masalah yang dihadapi.

[nelvin]

Tweet

[/list]Saya setuju dengan pendapat ini. Banyak developer pemula termasuk para pengarang lokal dan tenaga pendidik yang hanya berteori mengenai OOP. Pemahaman mereka tentu akan berkembang seiring dengan karir mereka.

OOP memang bisa diterapkan pada bahasa apapun bergantung pada disiplin developer yang terlibat. Akan tetapi, penerapan seperti ini akan mempersulit maintenance dan lebih rentan terhadap bug karena developer harus serba waspada.

Mungkin ini dapat dibandingkan dengan dulu saat programmer membuat program langsung dari bahasa mesin. Saat compiler pertama kali diperkenalkan, mereka meragukan kemampuan bahasa mesin yang dihasilkannya. Apa mungkin bahasa mesin program yang dibuat dengan compiler Pascal atau C lebih baik dari yang dibuat langsung oleh programmer itu sendiri? Tentu saja tidak. Tapi lihat saat ini, hanya developer nekat saja yang masih membuat program dari bahasa mesin dan menghindari penggunaan compiler.
OOP mungkin akan mengubah hidup developer, seperti saat compiler pertama kali diperkenalkan.



Di satu sisi, ini terasa tidak adil bagi programmer junior. Tapi ini jelas mempermudah pengembangan sistem. Kita akan dihadapkan dengan satu lagi lowongan baru bagi programmer, yaitu object engineer. Mereka bertugas membuat object dengan dokumentasi yang sangat jelas. Mereka menguji object mereka. Programmer kemudian memanfaatkan object buatan mereka untuk merancang perangkat lunak guna memecahkan masalah yang dihadapi.

Mungkin sudah saatnya untuk kembali ke laptop, kembali ke pemahaman paling basic dulu, dimulai dari pemahaman kenapa kita sekarang programming pakai bahasa high level, bukan pake assembly. Dan dr sini baru lanjut ke OOP. Mungkin karena OOP begitu "sexy", malu klo gak bisa, banyak yang maen tubruk ke sini dgn pemikiran begitu bisa pake bahasa yg object-oriented, berarti bisa OOP.

Ini sangat naif. Seperti halnya orang melukis. Bisa melukis adalah seperti bisa OOP. Bahasa prosedural adalah pensil hitam putih. Bahasa OO adalah cat warna. Orang yang bisa melukis, biarpun hanya pakai pensil hitam putih, lukisannya bagus juga. Yang tidak bisa melukis, walaupun pake cat warna, lukisannya juga pasti tidak bagus.

Selama kita sadar ini sih ok. Klo tidak, saya khawatir kalau dari awal sudah salah arah, dilanjutkan sampai kapanpun malah akan semakin hancur.

[mvx1n]

Tweet

setubuh, menurutku konsep utama oop adalah modularity atau kalo pake istilahmu ya lokalisasi. apalagi komentarmu soal operator overloading, asli itu, bukannya mempermudah kerjaan tp malah nambah pusing pas baca kodenya

• Encapsulation bisa disubtitusi dengan fungsi yang parameter pertamanya adalah handle. Contoh yang paling popular adalah Win32 API. Contoh:
  
  “objWindow.Resize(…”menjadi “WndResize(hWindow, …)“
  
  

contohmu ga gitu nyambung, setauku encapsulation itu artinya information hiding aka black box seperti yg kamu bahas. contohmu hanya menunjukkan perbandingan syntax tradisional dengan oop. hrsnya ditunjukkan suatu method yg berubah kode internalnya, tp tetap bisa dipanggil dengan cara yg sama dan output yg sama juga.

• Inheritance (yg katanya adalah untuk re-usable) bisa disubtitusi dengan mudah menggunakan “containment” (struktur data yang di dalamnya mempunyai struktur data lain). Contoh:

“class DialogBox : Window {…“ menjadi “class DialogBox {Window myParent; …“

• Polymorphism, well, ini dengan mudah disubtitusi menggunakan teknik penamaan fungsi yang baik, atau menggunakan fungsi yang parameternya struktur data. Contoh:

“CreateWindow(), CreateWindow(int xLoc, int yLoc)“ menjadi “WndCreateWindow(), WndCreateWindow_2(int xLoc, int yLoc)”

hmm, emang bisa sih, tp jadi kompleks dan relatif sulit dibaca kodenya dibanding yg oop.

[nelvin]

Tweet

setubuh, menurutku konsep utama oop adalah modularity atau kalo pake istilahmu ya lokalisasi. apalagi komentarmu soal operator overloading, asli itu, bukannya mempermudah kerjaan tp malah nambah pusing pas baca kodenya



contohmu ga gitu nyambung, setauku encapsulation itu artinya information hiding aka black box seperti yg kamu bahas. contohmu hanya menunjukkan perbandingan syntax tradisional dengan oop. hrsnya ditunjukkan suatu method yg berubah kode internalnya, tp tetap bisa dipanggil dengan cara yg sama dan output yg sama juga.



hmm, emang bisa sih, tp jadi kompleks dan relatif sulit dibaca kodenya dibanding yg oop.

Keliatannya kamu salah nangkep maksud dari artikelku. Tujuan dari artikel ini BUKAN untuk membandingkan bahasa OO dan prosedural. Utk ini sudah jelas syntax bahasa OO lebih praktis dan lebih kaya drpd bahasa prosedural. Dan saya juga setiap hari kerja pakai bahasa OO.

Tujuan utama dari sharing ini bahwa yang namanya OOP itu bukan hanya sekedar pakai bahasa OO. Kalau hanya bisa pakai bahasa OO, belum berarti mengerti OOP. OOP itu bukan sekedar masalah2 seperti bagusan inheritance atau containment, bagusan implementation inheritance atau interface inheritance, bagusan get-set atau assignment biasa, bagusan operator overloading atau fungsi biasa, bagusan polymorphism atau nama fungsi yg berbeda, dan-lain-lain. Ini semua hanyalah masalah SYNTAX, hanyalah tool, tidak akan membuat kita paham OOP. Ini yang keliatannya sering dilupakan.

Orang yang tidak bisa melukis, mau pakai cat warna sebagus apapun, lukisannya juga tidak akan bagus. Demikian juga dengan "melukis" program.

[nelvin]

Tweet

setubuh, menurutku konsep utama oop adalah modularity atau kalo pake istilahmu ya lokalisasi. apalagi komentarmu soal operator overloading, asli itu, bukannya mempermudah kerjaan tp malah nambah pusing pas baca kodenya



contohmu ga gitu nyambung, setauku encapsulation itu artinya information hiding aka black box seperti yg kamu bahas. contohmu hanya menunjukkan perbandingan syntax tradisional dengan oop. hrsnya ditunjukkan suatu method yg berubah kode internalnya, tp tetap bisa dipanggil dengan cara yg sama dan output yg sama juga.



hmm, emang bisa sih, tp jadi kompleks dan relatif sulit dibaca kodenya dibanding yg oop.

Keliatannya kamu salah nangkep maksud dari artikelku. Tujuan dari artikel ini BUKAN untuk membandingkan bahasa OO dan prosedural. Utk ini sudah jelas syntax bahasa OO lebih praktis dan lebih kaya drpd bahasa prosedural. Dan saya juga setiap hari kerja pakai bahasa OO.

Tujuan utama dari sharing ini bahwa yang namanya OOP itu bukan hanya sekedar pakai bahasa OO. Kalau hanya bisa pakai bahasa OO, belum berarti mengerti OOP. OOP itu bukan sekedar masalah2 seperti bagusan inheritance atau containment, bagusan implementation inheritance atau interface inheritance, bagusan get-set atau assignment biasa, bagusan operator overloading atau fungsi biasa, bagusan polymorphism atau nama fungsi yg berbeda, dan-lain-lain. Ini semua hanyalah masalah SYNTAX, hanyalah tool, tidak akan membuat kita paham OOP. Ini yang keliatannya sering dilupakan.

Orang yang tidak bisa melukis, mau pakai cat warna sebagus apapun, lukisannya juga tidak akan bagus. Demikian juga dengan "melukis" program.

[SolidSnake]

Tweet

Well, aku butuh berminggu-minggu untuk menyesuaian diri dari prosedural/modular ke OOP.. Benar2 perbedaan mindset dan cara pandang yang berbeda .. Tapi aku setuju, dasar dari pemograman tetap sama dimana-mana, yaitu algoritma-nya.. Tapi cara kita men-implementasi-kan algoritma mungkin bisa beda2: ada yang pakai OOP, ada yang pakai prosedural/modular, ada yang pakai konsep event-driven, dan terserah deh ..

Mungkin sudah saatnya untuk kembali ke laptop, kembali ke pemahaman paling basic dulu, dimulai dari pemahaman kenapa kita sekarang programming pakai bahasa high level, bukan pake assembly. Dan dr sini baru lanjut ke OOP. Mungkin karena OOP begitu "sexy", malu klo gak bisa, banyak yang maen tubruk ke sini dgn pemikiran begitu bisa pake bahasa yg object-oriented, berarti bisa OOP.

Wah, bahaya tuh kalo belajar OOP hanya demi ikut2an.. Tapi bahaya juga kalo menghindari OOP lho..
Aku nambahin informasi ya, siapa tahu berguna..

Bjarne Stroustrup dalam bukunya C++ Programming Language (AT&T, 1997, p.725) menyebutkan kegagalan perancang program dalam memanfaatkan kelebihan bahasa C++ atau gagal dalam memahami keterbatasan bahasa C++ meliputi:

1. Tidak mempedulikan class dan hanya merancang seperti dalam bahasa C.
Biasanya dilakukan oleh perancang dengan background C atau pemograman terstruktur.

2. Tidak mempedulikan derived class dan virtual function dan hanya menggunakan bagian data abstraction saja.
Biasanya dilakukan oleh perancang dengan background Ada83, Visual Basic, atau pemograman yang memanfaatkan data abstraction.

3. Tidak mempedulikan static type checking dan berusaha mensimulasikan dynamic type checking.
Biasanya dilakukan oleh perancang dengan background Smalltalk atau Lisp.

5. Merancang program atau sistem dengan tujuan melenyapkan programmer.
Biasanya dilakukan oleh perancang non-teknikal atau perancang yang sangat spesialis.

6. Tidak mempedulikan segalanya kecuali hierarki class.
Biasanya dilakukan oleh mereka yang menitik-beratkan pada OOP murni.

Beberapa alasan umum menghindari inheritance antara lain klaim bahwa "inheritance melanggar penyembunyian informasi" (well, yang dimaksud disini virtual functions dan protected member), atau "inheritance membuat kerja sama dengan software lain semakin susah".

Ini kutipan lagi:

In many cases, there is no real advantage to be gained from inheritance. However, in a large project a policy of "no inheritance" will result in a less comprehensible and less flexible system in which inheritance is "faked" using more traditional language and design constructs... In other words, keep an open mind. Class hierarchies are not an essential part of every good program, but in many cases they can help in both the understanding of the application and the expression of a solution. The fact that inheritance can be misused and overused is a reason for caution; it is not a reason for prohibition.

[nelvin]

Tweet

Well, aku butuh berminggu-minggu untuk menyesuaian diri dari prosedural/modular ke OOP.. Benar2 perbedaan mindset dan cara pandang yang berbeda .. Tapi aku setuju, dasar dari pemograman tetap sama dimana-mana, yaitu algoritma-nya.. Tapi cara kita men-implementasi-kan algoritma mungkin bisa beda2: ada yang pakai OOP, ada yang pakai prosedural/modular, ada yang pakai konsep event-driven, dan terserah deh ..



Wah, bahaya tuh kalo belajar OOP hanya demi ikut2an.. Tapi bahaya juga kalo menghindari OOP lho..
Aku nambahin informasi ya, siapa tahu berguna..

Bjarne Stroustrup dalam bukunya C++ Programming Language (AT&T, 1997, p.725) menyebutkan kegagalan perancang program dalam memanfaatkan kelebihan bahasa C++ atau gagal dalam memahami keterbatasan bahasa C++ meliputi:


Beberapa alasan umum menghindari inheritance antara lain klaim bahwa "inheritance melanggar penyembunyian informasi" (well, yang dimaksud disini virtual functions dan protected member), atau "inheritance membuat kerja sama dengan software lain semakin susah".

Ini kutipan lagi:

Setuju banget.

So klo ditambahkan usulan mata-kuliah programming dibuat seperti ini, gimana pendapat dari rekan2?

1. Algoritma, sebaiknya pseudo-code, supaya tidak terpengaruh dulu terhadap dialek2 dr bermacam2 language. Dalam hal ini, mungkin BASICA bisa jadi "tool" yang baik.

2. Assembly Language - seriously, supaya si developer punya bayangan paling "real" si mesin itu bekerjanya seperti apa sih. Banyak developer yang gak ngerti Assembly, pengertiannya jadi di "awang-awang" dan susah diajak ke bumi lagi

3. Konsep OOP - tapi tanpa menggunakan bahasa OOP, lagi pake pseudo-code, atau maksimum pakai BASICA. Jadi bisa konsentrasi dulu terhadap INTI dr OOP - belajar melukis yang lebih baik dululah istilahnya. Tapi tentu bukan yang isinya contoh keluarga buah2an atau binatang2. Pakai contoh nyata, pendekatan pembuatan dengan menggunakan prosedural gimana, dengan OOP gimana. Tunjukkan bedanya dalam bentuk nyata seperti : code yg lebih singkat, lebih sedikit error prone, mudah diubah, BERI CONTOH NYATA.

4. Baru bahasa OO. Dr sini baru dijelaskan kegunaan bahasa OO, dan tentu bakal nyambung 100% karena sudah mengerti konsep OOP. Dan baru bisa menghargai betapa berhaganya Bahasa OO.

5. Sekalian ditambahkan, bahasa OO, itu waktu di-compilasi jadi bahasa Assembly-nya seperti apa. Bukan seperti pelajaran kompilasi, tetapi langsung dikaitkan dengan contoh2 nyata hasil dari compilasi itu bentuk nyatanya di mesin seperti apa, contoh utk misalnya : call stack, local variable, virtual function, dll. Dengan demikian, seperti diingatkan terakhir kali, bahwa yg penting adalah bisa "melukis" (OOP-nya), bukan alat melukis-nya (bahasa OO-nya).

Gimana pendapat rekan-rekan? Baguskah ini? Ada yang perlu ditambahkan? Terlalu lamakah? Terlalu berlebihankah?