Announcement

Announcement Module
Collapse
No announcement yet.

Pemrograman yang hanya pemrograman

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pemrograman yang hanya pemrograman

    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.
    Last edited by nelvin; 30-12-2011, 04:47. Reason: Replaced by more valid article

  • #2
    <lanjutan...>

    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!
    Last edited by nelvin; 30-12-2011, 04:48. Reason: Replaced by more valid article

    Comment


    • #3
      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.

      Comment


      • #4
        Re: Pemrograman yang hanya pemrograman

        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.

        Comment


        • #5
          Re: Pemrograman yang hanya pemrograman

          Originally posted by The_Quantum View Post
          [/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.

          Comment


          • #6
            Re: What is OOP – Tiga Pilar OOP Itukah??

            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

            Originally posted by nelvin View Post
            • 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.

            Originally posted by nelvin View Post
            • 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.

            Comment


            • #7
              Re: What is OOP – Tiga Pilar OOP Itukah??

              Originally posted by mvx1n View Post
              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.
              Last edited by nelvin; 01-04-2007, 15:39.

              Comment


              • #8
                Re: What is OOP – Tiga Pilar OOP Itukah??

                Originally posted by mvx1n View Post
                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.
                Last edited by nelvin; 31-03-2007, 20:27.

                Comment


                • #9
                  Re: Pemrograman yang hanya pemrograman

                  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 ..

                  Originally posted by nelvin View Post
                  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.
                  Last edited by SolidSnake; 02-04-2007, 18:48.

                  Comment


                  • #10
                    Re: Pemrograman yang hanya pemrograman

                    Originally posted by SolidSnake View Post
                    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?
                    Last edited by nelvin; 02-04-2007, 21:11.

                    Comment


                    • #11
                      Re: Pemrograman yang hanya pemrograman

                      i think it's gonna be hard.

                      para tenaga pengajarnya (i am sorry), rata2......(put_answer_here)

                      gw kuliah gak ngerti2 soal programming.
                      baru pas belajar sendiri, ngerti. Thanx to K&R book for that

                      well, lagi2 soal SDM... :|

                      Comment


                      • #12
                        Re: Pemrograman yang hanya pemrograman

                        tambah pengetahuan nih, nice thread. cendol 4 u.

                        Comment


                        • #13
                          Perbedaan OOP dan Prosedural - Apakah Betul Ini Ada?

                          Banyak yang bertanya apakah perbedaan antara Prosedural dan OOP. Pertanyaan ini SALAH BESAR. Prosedural dan OOP bukan perbedaan. Tetapi:


                          OOP melengkapi teknik Prosedural,
                          BUKAN BERBEDA.


                          3.1. Salah Kaprah yang Berbahaya

                          OOP melengkapi Prosedural. Dan Prosedural melengkapi teknik… yang well karena belum ada namanya, jadi kita sebut saja Flow Programming (FP). Salah satu ciri dari FP adalah code banyak dipenuhi dengan “Goto”. Perbedaan cara pandang antara yang memandang “OOP adalah sebuah teknik pemrograman yang berbeda dengan Prosedural” dan cara pandang bahwa “OOP melengkapi Prosedural” sangat vital, dan ini salah satu reason yang menghasilkan banyak code yang tidak berkualitas – hanya karena sekedar mau OOP “murni”.

                          Mengapa berpikir “melengkapi” dan berpikir “berbeda” bisa menimbulkan salah kaprah yang dahsyat?

                          1. Dengan anggapan berbeda, maka orang menganggap Prosedural lebih baik daripada FP. Jadilah “Goto” menjadi kambing hitam, dan semua orang beramai-ramai menghindari “Goto”. Padalah “Goto” sangat baik untuk error-handling (tentu sebelum ada syntax Try-Catch-Finally). Dan saya yakin masih ada kegunaan “Goto”, kita hanya perlu open-mind.

                          2. Dengan anggapan berbeda, maka orang menganggap cara berpikir OOP lebih baik dari Prosedural. Jadilah anggapan bahwa semua harus dibuat “Class”, “di-Inherit”, dan-lain-lain, sehingga code dipenuhi dengan class dan inheritance-nya yang sangat menggelikan. Menggelikan karena sudah pakai class dan inheritance yang sebanyak-banyaknya (di setiap jengkal code yang mungkin), tetapi code-nya tetap saja penuh bug dan susah dimengerti. Lukisannya tetap saja tidak indah dipandang.

                          3.2. Aplikasi Komputer

                          Sebelum kita lanjut diskusi dengan seru mengenai objet-oriented, tentu kita harus menyamakan dulu tujuan kita semua. Kalau kita tidak agree dengan tujuan akhirnya, diskusi ini bakal jadi debat kusir tanpa ujung.

                          3.2.1. Yang Pertama Jelas : User Membutuhkan Aplikasi Komputer

                          Yang pertama, apapun makanannya, tujuan akhirnya sudah jelas adalah membuat aplikasi yang berguna untuk user. Aplikasi yang berguna adalah aplikasi yang:

                          1. Biayanya bisa terjangkau oleh user.

                          2. Bug-nya tidak terlalu banyak, masih bisa diterima-lah (tidak ada aplikasi yg bug-free).

                          3. Berjalan sesuai dengan fungsi yang diinginkan oleh user.

                          4. Dan sangat banyak lagi.

                          Daftar ini bisa panjang sekali. Tetapi sudah pasti tidak ada satu-pun requirement dari user yang mengatakan saya mau program yang didesain secara object-oriented, mau programnya ditulis pake C# (atau VB.net), harus mengandung class dan inherintance, dan lain-lain yang seperti itu. Hanya orang teknikal (atau programmer alias kita) yang concern dengan itu. USER TIDAK PEDULI, buat mereka adalah aplikasi jalan, harganya masuk, dan dideliver tepat waktu.

                          3.2.2. Apakah itu Aplikasi Komputer

                          Ok, berarti ada kebutuhan aplikasi komputer. Aplikasi komputer itu apa? Yaitu merupakan rentetan instruksi yang harus dieksekusi oleh mesin. Dalam arti yang paling sederhana, setiap code kita akan dieksekusi oleh mesin step-by-step, persis seperti kalau kita membuat program di Bahasa BASIC yang ada line number-nya. Betul-betul seperti itu. Bagi yang mempelajari Bahasa Assembly, tentu mengerti bahwa processor itu pada dasarnya adalah INTERPRETER. Mereka baca instruksi dari code kita, mengeksekusinya, setelah itu loncat ke code mana (goto), evaluasi if-goto-else-goto-else2-goto2-dst.

                          Ini adalah arsitektur komputer yang sudah didesain kurang-lebih 100 tahun yang lalu oleh jenius matematika Von Newman. Apapun juga bahasa-mu, bagaimanapun desainnya, bagaimanapun trick-nya, ujung-ujungnya akan selalu menjadi instruksi yang harus dieksekusi oleh processor. Di hasil akhir sudah tidak ada lagi itu istilah bahasa OO, OOP, prosedural, dan lain sebagainya.

                          3.3. Selanjutnya : Ya Membuat Aplikasi Komputer Itu

                          Bahwa apapun juga caranya, tujuannya adalah bagaimana kita menghasilkan urutan-urutan instruksi komputer. Perkara mau pakai OOP atau prosedural, itu teknik, bukan tujuan akhir. Itu adalah sebuah teknik, yang disempurnakan dengan teknik berikutnya, dan seterusnya, dengan tujuan kita dapat menghasilkan instruksi untuk komputer, dengan usaha yang efisien dan dengan tingkat kesulitan yang masih dalam batas-batas manusia normal.

                          Klo di-sumarize:

                          1. User butuh aplikasi komputer.

                          2. Aplikasi komputer = urutan instruksi.

                          3. Oleh karena itu kita membuat urutan instruksi (definitely bukan buat aplikasi komputer yang OOP).

                          Jadi seharusnya tujuan akhir desain dan bahasa komputer adalah membantu kita membuat urutan-urutan instruksi untuk komputer. Jelas desain dan bahasa bukan tujuan akhir, ini hanya cara. Cara ini yang berkembang sampai dengan sekarang menjadi OOP dan bahasa OO.

                          So mari kita mulai runut, bagaimana ceritanya sampai jadi aplikasi komputer. Dari sini diharapkan jelas, bahwa tidak ada teknik yang completely menggantikan teknik sebelumnya, tetapi merupakan kelanjutan, dengan tujuan “kita membuat aplikasi komputer, dengan cara yang semakin efisien dan efisien”.

                          3.3.1. Langkah Awal Membuat Aplikasi Komputer

                          Mari kita berimajinasi sedikit. Coba dibayangkan pada saat sebuah processor baru selesai dibuat. Bagaimana memberikan perintah ke processor. Tentu pertama kita menuliskan perintah ini. Untuk yang belum mengenal Bahasa Assembly, jangan bayangkan kita menulis print(“Hello World”), jauh banget. Kita menuliskan dalam kode-kode angka-angka, YAIK, angka-angka. Angka-angka ini tentu yang mempunyai arti bagi si processor. Misalnya kita mau menjumlah angka 5 + 8. Instruksinya kira seperti ini (sedikit background : register adalah memori internal dari processor):

                          1. 0105 (yang artinya taroh angka lima di register X).

                          2. 0208 (yang artinya taroh angka delapan di register Y).

                          3. 03 (yang artinya jumlahkan angka di register X dan register Y, hasilya taroh di register Z).

                          Nah angka-angka ini kita taroh di sebuah media, bisa RAM, klo jaman dulu di punch-card, pokoknya apapun itu yang bisa disambung ke processor, sehingga processor bisa membacanya. Instruksi-instruksi tersebut biasanya digabung kira-kira menjadi seperti “0105020803”, kita upload ke RAM / atau punch-card, sambung ke processor, trus jalankan processor tersebut (dengan memasang baterai / listrik, kemudian switch-on gitulah kira2).

                          Inilah teknik programming yang pertama. Perhatikan : kita membuat urutan instruksi.

                          3.3.2. Lahirnya Bahasa Assembly

                          Contoh di atas hanyalah ilustrasi singkat saja untuk menunjukkan betapa repotnya memberikan instruksi dalam bahasa mesin “murni”. Bayangkan betapa rumitnya perintah yang harus diberikan kalau kita mau memerintahkan ini sampai dengan tampil di layar. Apalagi klo mau tampil di GUI Windows / Mac / Linux. Bisa kebayangkan ini akan menjadi sebuah pekerjaan yang hampir impossible buat manusia normal (programmer juga manusia ya).

                          Memberikan perintah semacam “0105020803”, tentu bikin sakit kepala. Oleh karena itu diciptakanlah Bahasa Assembly. Mungkin ada yg berpikir : kenapa Bahasa Assembly, kenapa gak langsung aja ke salah satu bahasa tingkat tinggi? Bisa saja, tapi kebayang gak pusingnya bikin compiler, misalnya untuk yang bahasa yang relatif mudah dicompile seperti Bahasa BASIC deh, kalo kita mesti ngomong dengan bahasa dedemit seperti “0105020803………….”.

                          Ok klo kita mesti step by step, make sense dong. Kan kita buat Rain-man (orang yang klo ada kotak korek api penuh, terus korek apinya dijatuhkan semua ke tanah, sebelum semua korek api tersebut sampai ke tanah, dia sudah bisa hitung berapa jumlah korek api tersebut).

                          So jika kita punya Bahasa Assembly… maka programming kita bentuknya menjadi lebih human karena urutan instruksi bukan berupa angka-angka di atas, melainkan berubah menjadi tulisan yang bisa kita baca dengan lebih mudah seperti berikut:

                          1. MoveX, 5

                          2. MoveY, 8

                          3. SumXY

                          Ini lebih gampang, dan terutama bikin compiler-nya juga gampang. Semuanya hampir one-to-one dengan kode angkanya. Gak perlu ilmu parser yang rumit. Jauh lebih gampang. Karena compiler Assembly ini code utama-nya paling banter isinya kira-kira begini:

                          1. Baca text.

                          2. Jika text = “MoveX” then

                          a. Output “01”

                          b. Baca text

                          c. Output text tsb (yaitu 05)

                          d. Goto nomor 1

                          3. Jika text = “MoveY” then

                          a. Output “02”

                          b. Baca text.

                          c. Output text tsb (yaitu 08)

                          d. Goto nomor 1

                          4. Jika text = “SumXY” then

                          a. Output “03”

                          b. Goto nomor 1

                          5. Dan-seterusnya-seterusnya.

                          Compiler yang logikanya begini, tentu masih mungkin ditulis dengan kode-kode angka tadi. Bandingkan jika harus langsung membuat compiler Bahasa BASIC.

                          INILAH TEKNIK PROGRAMMING KEDUA. TUJUAN TETAP : MEMUDAHKAN KITA MEMBUAT URUTAN INSTRUKSI.

                          3.3.3. Lahirnya Bahasa Tingkat Tinggi

                          Nah untuk orang, klo mo memberikan perintah 5 + 8, walaupun sudah menggunakan Bahasa Assembly, harus beberapa instruksi, dan ditambah untuk mengerti itu mau apa masih perlu olah mental lagi, tentu bikin repot. Belum lagi komputer yang nyaman tentu perlu harddisk, keyboard, monitor, dll. Si processor bahkan tidak mengenal itu semua. Yang dikenal hanya IO-bus. Processor hanya membaca instruksi, mengkalkulasi, dan kemudian mengirimkan sinyal-sinyal listrik kode melalu IO-bus. Sinyal-sinyal ini yg diterima oleh monitor, keyboard, dan peripheral lain, kemudian ditampilkan di monitor, disimpan ke harddisk, atau dikirim ke network card.

                          Kebayang berapa panjang code-nya untuk melakukan itu semua.

                          Kita mau yang lebih simple.

                          So mengapa tidak kita ciptakan saja sebuah bahasa baru. Yang kalo mau menjumlahkan 5 + 8, cukup tulis “5 + 8”, kemudian hasilnya langsung tampil di layar. Inilah yang disebut sebagai bahasa tingkat tinggi, karena kita menulis code dalam simbol-simbol yang bisa kita baca dengan lebih mudah.

                          Jadi kita perlu interpreter / compiler bahasa tingkat tinggi yang kalo diberikan input “5+8”, bisa langsung mengubah itu menjadi : “0105020803…” dan hasilnya langsung tampil di layar. Ini lebih simple / lebih human. Dan akan saving waktu programming sangat jauh.

                          Setelah punya Bahasa Assembly, tentu pekerjaan membuat interpreter / compiler bahasa tingkat tinggi ini lebih mungkin (dibandingkan klo harus menulisnya dalam bentuk kode-kode angka). Karena energi yang tadinya kita pakai untuk mendisplay, atau sekedar menjumlah, karena hal-hal itu sulit, bisa kita gunakan untuk berkonsentrasi di algoritma dari parser.

                          NOTE beberapa tentu sudah kepikir… sebelum kita membuat compiler bahasa apapun itu, bisa jadi kita buat dulu Bahasa Assembly versi 2 yang lebih sophisticated (misalnya menambahkan fitur untuk menulis komentar program), menggunakan Bahasa Assembly versi 1 (yang kita buat dengan kode-kode angka), kemudian membuat Bahasa Assembly versi 3 menggunakan Bahasa Assembly versi 2, dan seterusnya, sampai dengan kita mempunyai sebuah versi Bahasa Assembly yang cukup sophisticated untuk membuat bahasa tingkat tinggi pertama kita.

                          Apapun bahasa itu, mestinya bahasa semacam Bahasa BASIC yang syntaxnya sangat sederhana – yang bahkan tidak mempunyai prosedur, hanya “Goto” yang gampang diparser, sehingga parsernya juga lebih sederhana – sehingga mungkin dibuat oleh manusia menggunakan Bahasa Assembly.

                          Saya tidak akan menjelaskan detil itu, karena sesimple-simple-nya bahasa tingkat tinggi sudah memerlukan ilmu parser yang mulai rumit dan di luar pokok bahasan artikel ini. Yg penting poinnya sama dengan tadi. Kira-kira misalnya setelah dibuat bahasa tingkat tinggi sederhana, kita buat bahasa tingkat tingkat tinggi versi 2 menggunakan versi 1, buat versi 3 menggunakan versi 2, dan seterusnya, dan sampailah ke Bahasa BASIC yang cukup sophisticated untuk membuat sesuatu yang lebih sophisticated.

                          Anw, inilah lahirnya teknik programming ketiga : programming menggunakan bahasa tingkat tinggi. TUJUAN TETAP TIDAK BERUBAH : MEMUDAHKAN KITA MEMBUAT URUTAN INSTRUKSI.

                          Jadi dinote tujuan membuat urutan instruksi tidak berubah. Hanya klo sebelumnya kita mesti nulis (diulang lagi untuk memudahkan perbandingan):

                          1. MoveX, 5

                          2. MoveY, 8

                          3. SumXY

                          4. Dan-seterusnya-seterusnya...

                          Sekarang cukup:

                          1. 5 + 8

                          Klo ditanya mengapa pakai bahasa tingkat tinggi? Ini jelas, karena daripada menulis puluhan, bahkan mungkin ratusan baris code, kita cukup menulis satu baris code. Jelas benefit yang luar biasa.

                          Kita agak jump sedikit. Klo pertanyaannya adalah : mengapa pakai OOP? Kemudian dijawab : misalnya ada class kucing yang diturunkan dari class mamalia, kemudian kalo dulunya kita mesti nulis “makan(kucing.parent)”, sekarang cukup “makan(mamalia)”. Kita hanya benefit ENAM karakter. Jelas meragukan. Padahal dengan OOP terbukti banyak program semakin canggih bisa ditulis karena menggunakan teknik OOP. Jadi bukan karena masalah syntax lagi. There must be something else. Ok lets go on.

                          3.3.4. Lahirnya Bahasa Prosedural

                          Dengan bahasa tingkat tinggi yang primitif seperti bahasa BASIC (yang duluuuuu banget), program mengandalkan instruksi semacam “goto” dan semuanya adalah global variable. Ini memusingkan, paling sedikit karena dua alasan utama:

                          1. Banyak kumpulan dari code yang bisa digunakan di banyak tempat, susah digunakan.

                          2. Semua variable adalah global variable.

                          Berikut adalah contoh yang menunjukkan masalah di atas. Misalnya kita mempunyai fungsi untuk menghitung faktorial sebagai berikut ( moga2 algoritmanya bener ):

                          HitungFaktorial: //Parameter X = jumlah suku dari faktorial.
                          //Parameter R = kemana kita harus return.
                          //Return F = hasil dari faktorial.
                          F = 1;
                          For L = 1 To X
                          F = F * L;
                          Next L;
                          If R = “LanjutCalc” Goto LanjutCalc //Return ke pemanggil.
                          If R = “LanjutDisplay” Goto LanjutDisplay //Return ke pemanggil.
                          If R = “LanjutDadu” Goto LanjutDadu //Return ke pemanggil.
                          ExitMessage = “BUG : parameter kembali kemana tidak disebutkan.”
                          Goto Exit

                          Jadi si pemanggil untuk menggunakan ini, harus melakukan sbb:


                          X = 10; //Mau hitung nilai dari faktorial 10.
                          R = “LanjutCalc”; //Supaya kembali ke laptop.
                          Goto HitungFaktorial
                          LanjutCalc:


                          Ini jelas bermasalah. Masalah2nya adalah:
                          1. (masalah ringan) Waktu mau return dari fungsi repot sekali.

                          2. (BERAT) Begitu program berhenti dan keluarkan message “BUG : parameter kembali kemana tidak disebutkan.”, kita tidak punya ide code yang mana menyebabkan ini. Ini mulai mencari kutu, dan ini masalah berat karena bisa menghabiskan waktu sangat banyak.

                          3. (BERAT) Bagaimana jika pemanggil kebetulan menggunakan variable “F”, bisa pusing mencari sebab kenapa program tidak jalan (yang ternyata disebabkan variable “F” digunakan di salah satu pemanggil fungsi HitungFaktorial).

                          4. (BERAT) Label-label seperti “LanjutCalc” yang bersifat global memungkinkan sebuah code yang ntah dimana bisa nyasar ke sini. Dan ini juga dijamin nyarinya bakal nyari kutu.

                          Oleh karena itu diciptakanlah yang disebut “fungsi beneran” yang sifatnya kalau mau balik ke pemanggil, cukup tulis “return”. Dan diciptakanlah local variable. Sehingga menjamin variable “L” maupun “F” di dalam fungsi HitungFaktorial TIDAK MEMPUNYAI EFEK TERHADAP SIAPAPUN.

                          Jika ditulis ulang codenya menjadi seperti ini:

                          HitungFaktorial(Lokal X) //Parameter X = jumlah suku dari faktorial.
                          Local F = 1;
                          For Local L = 1 To X
                          F = F * L;
                          Next L;
                          Return F;

                          Mari kita analisis apa manfaat terbesarnya:

                          1. Syntax lebih sedikit, jelas benefit. Akan tetapi benefitnya kecil karena ini hanya menghemat ketikan. Apalagi klo si programmer adalah typist ulung (please yang belum bisa ngetik, belajar ngetik, ini jelas membantu banget). Total penghematan mungkin hanya beberapa menit per-panggilan. BETUL-BETUL HANYA SEMENIT-DUA MENIT. Yaitu klo tadinya setiap kita mau panggil fungsi HitungFaktorial, kita selalu harus tambahin sebuah baris code untuk return (misalnya : “If R = “MyFunction” Goto MyFunction”), sekarang sudah tidak perlu lagi.

                          2. Penghematan waktu karena sekarang sudah tidak bakal lagi ada kejadian si fungsi gagal untuk return SUDAH TIDAK ADA LAGI. Ini hematnya bisa berjam-jam, bisa berhari-hari. Karena coba dibayangkan klo pemanggil fungsi HitungFaktorial ada 100, pas ada error tersebut, mesti abis berapa jam? Berapa hari? Ini jauh dibandingkan penghematan beberapa menit karena alasan syntax di nomor satu.

                          3. Penghematan waktu karena sudah tidak ada lagi code yang kebetulan salah satu variable-nya dipakai oleh fungsi HitungFaktorial tersebut. Dengan alasan yang sama dengan nomor 2, ini hematnya bisa jam-jaman, bahkan hari-harian.

                          4. Penghematan waktu karena sudah tidak ada lagi code yang ntah dimana nyasar ke sebuah label yang ntah dimana juga. Dengan alasan yang sama dengan nomor 2, ini hematnya bisa jam-jaman, bahkan hari-harian.

                          Nah kalo cara pandang yang digunakan adalah menarik kesimpulan dengan cepat (tetapi salah), yang menjadi salah kaprah pada umumnya, keliatan serupa, TAPI TIDAK SAMA, yaitu:

                          1. Goto JELEK! Pokoke program sing ana “goto” JELEK.

                          2. Global variable JELEK! Pokoke program sing ana “global variable” JELEK.

                          Klo contohnya seperti di atas, “kebetulan” pandangan seperti ini ok-ok saja. Tapi sayangnya dunia programming membutuhkan seribu satu macam code selain daripada contoh di atas.
                          Last edited by nelvin; 05-04-2007, 16:19.

                          Comment


                          • #14
                            Lanjutan...

                            3.3.4.1. “Goto” Jelek?

                            Bagaimana kita solving problem error handling seperti ini. Ada sebuah fungsi yang mempunyai empat parameter, dan setiap parameter harus kita cek valid atau tidak, kalau tidak valid, harus mengembalikan sebuah error yang mengindikasikan parameter mana yang tidak valid. Kalau tanpa “Goto”:

                            HitungSomething(Local A, Local B, Local C, Local D)
                            If A = valid then
                            If B = valid then
                            If C = valid then
                            If D = valid then




                            Else
                            Return “Error-D”;
                            Endif
                            Else
                            Return “Error-C”;
                            Endif
                            Else
                            Return “Error-B”;
                            Endif
                            Else
                            Return “Error-A”;
                            Endif

                            Kemudian si pemanggil HitungSomething juga mesti lakukan ini juga:

                            Local X = HitungSomething(1, 2, 3, 4);
                            If X = “Error-A” or X = “Error-B” or X = “Error-C” or X = “Error-D” then
                            Return X;
                            Else
                            X = HitungSomethingElse(1, 2, 3);
                            If X = “Error-A” or X = “Error-B” or X = “Error-C” then
                            Return X;
                            Else




                            Endif
                            Endif

                            Coba kita coba dengan “Goto”:

                            HitungSomething(Local A, Local B, Local C, Local D)
                            If A <> valid then
                            E = “Error-A”;
                            Goto Error;
                            Endif
                            If B <> valid then
                            E = “Error-B”;
                            Goto Error;
                            Endif
                            If C <> valid then
                            E = “Error-C”;
                            Goto Error;
                            Endif
                            If D <> valid then
                            E = “Error-D”;
                            Goto Error;
                            Endif





                            Dan code si pemanggil HitungSomething juga cukup juga menjadi:

                            HitungSomething(1, 2, 3, 4);
                            HitungSomethingElse(1, 2, 3);





                            Code menjadi lebih singkat. Dan yang terutama alur utama program lebih jelas terbaca.
                            Kalau kita berpikiran “Goto” jelek, tentu kita tidak akan pernah menggunakan “Goto”. Tetapi kalau kita mengerti dengan baik alasan kenapa “Goto” jelek, kita bisa menghindari penggunaan “Goto” yang jelek, dan menggunakannya di area dimana “Goto” berfungsi dengan lebih baik. Jadi yang bermasalah bukanlah “Goto”-nya, karena ini-kan hanya sekedar fitur, salah satu senjata dari gudang senjata kita, tergantung kita sendiri bagaimana memanfaatkannya.

                            Dan oleh karena itu, kalau diperhatikan, sebenarnya fitur-fitur seperti Try-Catch-Finally, bisa return dari mana saja, exit di tengah-tengah loop, suddenly balik ke awal loop, adalah salah satu bentuk “Goto”. Saya menyebutnya sebagai “Goto”-TERARAH. Terarah karena potensi penggunaan “Goto” yang buruk dicegah.

                            Bahkan di dunia bahasa OO masa kinipun, “Goto” murni masih bisa berguna. Kalau suatu hari Anda menemukan code yang terlalu banyak indentasi ke kanan, mau diapapun juga, tetap indentasi ke kanan juga, coba think solusi menggunakan “Goto”.

                            3.3.4.2. “Global Variable” Jelek?

                            Coba bayangkan kalau kita mempunyai aplikasi yang mempunyai katakanlah 10 variable yang sifatnya system-wide. Misalnya : koordinat kiri atas dari window aplikasi, lebar, tinggi, warna button, warna textbox yang error, warna textbox yang mandatory, dan-lain-lain. Bayangkan kalau kita hanya berpikiran global variable jelek. Kita akan menghindari penggunaan global variable. Dan sebagai gantinya, setiap kali kita mau memanggil fungsi yang membutuhkan variable-variable tersebut, kita harus selalu mempassing ke-10 variable tersebut sebagai parameter. Bagaimana jika variable yang system-wide tersebut bertambah menjadi 20. Haruskan kita mengedit setiap fungsi satu-satu? Bukankah ini membuah code menjadi semakin ruwet? Dan tujuan kita menggunakan bahasa prosedural-kan supaya kita bisa menulis instruksi dengan lebih efisien dan hemat tenaga. Bukankah dengan menghindari global variable seperti ini malah semakin membuang energi dan waktu kita?

                            Global variable yang jelek adalah karena yang menggunakannya tidak mengerti cara menggunakannya. Global variable sendiri hanyalah fitur, bermanfaat atau malah merusak, tergantung dari yang menggunakannya.

                            3.3.4.3. Sedikit Kesimpulan sebelum Membahas OOP

                            Dengan semakin canggihnya bahasa OO, mungkin contoh-contoh di atas terlihat primitif sekali. Poinnya bukan di situ. Justru sengaja dengan pembahasan bahasa prosedural dibandingkan bahasa non-prosedural, yang lebih simple, diharapkan bisa lebih terlihat bahwa “mengapa” sebuah fitur bahasa diciptakan. Dengan mengerti “mengapa”-nya ini, dan bukan keyakinan close-minded seperti “ini dilarang”, “itu jelek”, “itu menyalahi aturan prosedural”, menjamin kita bisa berkreasi dengan lebih baik dan tidak terjebak dengan keyakinan-keyakinan tidak berdasar yang malah membuat code menjadi lebih rumit.

                            Jika contoh yang sederhana seperti di atas bisa dipahami, barulah kita siap membahas OOP yang lebih kompleks. Akan tetapi konsepnya tetap sama : memudahkan kita menghasilkan urutan instruksi.

                            3.4. 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.

                            3.4.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.



                            Misalnya klo di aplikasi kita mempunyai sebuah window dimana hasil dari setiap output kita harus ditampilkan di dalam window tersebut.

                            3.4.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).

                            3.4.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.

                            3.4.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.

                            3.4.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.

                            3.5. 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.

                            Happy programming!
                            Last edited by nelvin; 05-04-2007, 16:31.

                            Comment


                            • #15
                              Re: Lanjutan...

                              subscribed...

                              g termasuk golongan yang mikir goto & global var jelek nih...hehe....thx pencerahan nya...moga2 coding g makin efisien dgn ikutin saran u

                              Comment

                              Working...
                              X