Pemrograman yang hanya pemrograman - Page 2
Welcome guest, is this your first visit? Create Account now to join.
  • Login:

Welcome to the CHIP Forum.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed.

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 25

Thread: Pemrograman yang hanya pemrograman
  
Bookmark and Share

  1. #11
    Join Date
    Jan 2005
    Posts
    1,027
    Thanks
    0
    Thanked 3 Times in 3 Posts
    Rep Power
    21

    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... :|
    No Sig

  2. #12
    Join Date
    Aug 2004
    Location
    jambi
    Posts
    2,106
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Rep Power
    26

    Re: Pemrograman yang hanya pemrograman



    tambah pengetahuan nih, nice thread. cendol 4 u.

  3. #13
    Join Date
    Mar 2007
    Posts
    14
    Thanks
    0
    Thanked 1 Time in 1 Post
    Rep Power
    0

    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:

    <do something>
    X = 10; //Mau hitung nilai dari faktorial 10.
    R = “LanjutCalc”; //Supaya kembali ke laptop.
    Goto HitungFaktorial
    LanjutCalc:
    <lanjut dengan do something else>

    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 at 16:19.

  4. #14
    Join Date
    Mar 2007
    Posts
    14
    Thanks
    0
    Thanked 1 Time in 1 Post
    Rep Power
    0

    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
    <Do something>
    <Do something>
    <Do something>
    <Do something>
    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
    <Do something>
    <Do something>
    <Do something>
    <Do something>
    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
    <Do something>
    <Do something>
    <Do something>
    <Do something>

    Dan code si pemanggil HitungSomething juga cukup juga menjadi:

    HitungSomething(1, 2, 3, 4);
    HitungSomethingElse(1, 2, 3);
    <Do something>
    <Do something>
    <Do something>
    <Do something>

    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.

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

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

    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 at 16:31.

  5. #15
    Join Date
    May 2005
    Posts
    2,348
    Thanks
    79
    Thanked 11 Times in 10 Posts
    Rep Power
    26

    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
    worklog-1 : Casing AT to ATX
    worklog-2 : Simbadda Watercooled Reversed ATX
    guide-1 : Universal IR Remote Receiver

    "back in the day" the fun of overclocking was taking mid-low range hardware to the speeds of the top end hardware and beyond. Not spending as much as possible initially to take the top end hardware a bit further.

  6. #16
    Join Date
    Jul 2005
    Location
    Jakarta
    Posts
    114
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Rep Power
    17

    Re: Lanjutan...



    Wah, rasanya baru pertama kali ini saya nemu posting yang seperti ini. Konsep2 seperti inilah yang tidak diajarkan dengan baik di kuliahan... Saya sendiri lumayan setuju dengan postingan2 anda , memang banyak orang belajar bahasa OO tapi tidak memrogram dengan konsep OOP... Sekedar bisa bahasa Java/C++ tapi memakainya sama saja dengan bahasa C, semua fungsi taruh di satu class, dan sebagainya.

    Kebetulan kalo di kampus sih saya ada mata kuliah yang namanya Object Technology, yang intinya mengajarkan cara menggunakan OOP yang benar (benar - benar OOP, bukan bahasanya, tapi konsep objectnya). Course ini mengajarkan kapan harus pakai inheritance, kapan harus pakai private, dll...

    Pengalaman saya memrogram dalam berbagai bahasa (asm, c, c++, pascal, java, php, dll...) juga rata2 sesuai dengan pendapat anda. Kebanyakan konsep2 keren yang ada di buku tidak cocok dengan dunia nyata implementasi program bila dipakai "sekedar biar keren".

    Di bahasa C++ ada satu feature selain operator overloading yang lebih keren lagi, di mana kita bisa declare yang namanya macro. Menurut bahasanya, C/C++ tidak ada yang namanya looping foreach, tapi anda bisa declare sendiri pake macro untuk bisa foreach yang kompatible dengan kontainer2 STL yang support iterator. Memakainya tinggal FOREACH(nama iterator,nama container){}. Beberapa programmer bahkan define FOR(i,n) untuk merepresentasikan for (int i=0;i<n;i++), dan sebagainya. Feature2 keren seperti ini tidak ada di Java... Memang tidak banyak gunanya kalo untuk programming yang standar memakai feature2 keren di atas, tapi ada kalanya memang diperlukan, misalnya ketika kecepatan coding sangat penting (misalnya dalam lomba).

    Tapi saya agak kurang setuju dengan contoh penggunaan GOTO di atas.(kalo saya tidak salah nangkep), struktur contoh anda begini kan

    myProcedure(){

    hitungSomething() -> di dalamnya akan goto error
    hitungSomethingElse() -> di dalamnya akan goto error
    <dosomethingElse>
    <dosomethingElse>
    error:
    <errornyadisini>

    }

    Kesalahannya :
    - Ini membuat fungsi hitungSomething dan hitungSomethingElse tidak bisa dipakai selain oleh myProcedure. Tidak masalah sih, kalo memang anda buat fungsi cuma dipake di situ. Gak lucu kan kalo anda panggil hitungSomething dari iniProcedureLain() tapi ujung2nya kalo error dia goto myProcedure, padahal gunanya beda.
    - Ini membuat error tracing amat sulit (kalo kasusnya cuma kecil kayak dicontohkan sih gampang, coba kalau hitungSomething masih panggil function2 lainnya, dll. Sangat tidak logis buat sebuah fungsi yang TIDAK return ke tempat semula. Konsep yang begini memang normal untuk programming bahasa assembly, yang tidak function-oriented, tapi tidak untuk programming standar sehari2 yang pake bahasa non-assembly. Walopun pas coding rasanya enak... gak pusing, tapi tetep saja tidak feasible untuk skala besar.
    - Untuk contoh di atas, seandainya anda pake bahasa OO yang sudah support Exception (walopun exception tidak begitu bisa dikategorikan bagian dari OO), solusinya jauh lebih mudah. Yang saya suka dari exception adalah pembedaan antara return value dengan error return. Membuat fungsi yang return -1 bila error mungkin sah sah saja, tapi tidak lucu kalau membuat fungsi yang bisa return string apa saja (misalnya concatenate(string1, string2) tapi kalo error returnnya sebuah string juga "error", maka fungsi di atas akan salah bila ada orang concatenate("err","or"). Pemisahan antara return value dan return error amat penting diperhatikan, kalo gak bisa digabung, jangan digabung.

    Saya sendiri tidak anti pakai goto, asalkan pemakaiannya masuk akal. Goto menurut saya adalah baik dipakai selama memang diperlukan dan ada dalam satu fungsi yang sama. Banyak pengalaman goto bisa menyederhanakan coding (flatten coding yang bakal repot kalo pake if bertingkat2, ato untuk kondisi break nested looping yang rumit), tapi tidak untuk contoh anda di atas.

    Kalo sekadar untuk error handling, tanpa exception, untuk contoh anda di atas saya lebih prefer solusi begini. (asumsi anda pakai variable global E untuk simpan error, saya pake variabel global F untuk simpan flag, dan E untuk simpan error, asumsi hitungsomething adalah void)

    HitungSomething(Local A, Local B, Local C, Local D)
    {
    If A not valid then F = true; E = "Error-A"; return; end if
    If B not valid then F = true; E = "Error-B"; return;end if
    If C not valid then F = true; E = "Error-C"; return;end if
    If D not valid then F = true; E = "Error-D"; return;end if
    If E not valid then F = true; E = "Error-E"; return;end if
    <Do something>
    <Do something>
    <Do something>
    <Do something>
    }

    Hitungsomethingelse juga sama aja.

    myProcedure(){
    ..
    F = false;
    hitungSomething(1,2,3,4,5);
    if (F) goto error;
    hitungSomethingElse(6,7,8);
    if (F) goto error;

    }

    Dengan demikian codingnya jelas, tidak rumit, dan masuk akal, fungsi return ke tempat seharusnya, dan tidak asal loncat ke tempat lain yang tidak jelas. Setahu saya juga kayaknya bahasa pemrograman yang saya tahu tidak mengijinkan goto antar fungsi (karena function call itu kan sebuah entity di stack memory, tidak mungkin kalo dia goto ke function lain, karena function itu single-entry point di mana variabel lokal dan parameternya akan dipush ke stack, kalo masuk dari tengah pake goto, kalopun bisa, variabel lokalnya bakal berantakan karena gak diinit).

    Kalau saja contoh anda adalah isi dari fungsi ato procedure yang sama (bukan panggil2 fungsi lain dan goto ke fungsi lain lagi), tentu saya akan setuju dengan cara anda memakai goto.

    -Kurniady

  7. #17
    Join Date
    Mar 2007
    Posts
    14
    Thanks
    0
    Thanked 1 Time in 1 Post
    Rep Power
    0

    Re: Lanjutan...



    Quote Originally Posted by Tensor View Post
    Dengan demikian codingnya jelas, tidak rumit, dan masuk akal, fungsi return ke tempat seharusnya, dan tidak asal loncat ke tempat lain yang tidak jelas. Setahu saya juga kayaknya bahasa pemrograman yang saya tahu tidak mengijinkan goto antar fungsi (karena function call itu kan sebuah entity di stack memory, tidak mungkin kalo dia goto ke function lain, karena function itu single-entry point di mana variabel lokal dan parameternya akan dipush ke stack, kalo masuk dari tengah pake goto, kalopun bisa, variabel lokalnya bakal berantakan karena gak diinit).

    Kalau saja contoh anda adalah isi dari fungsi ato procedure yang sama (bukan panggil2 fungsi lain dan goto ke fungsi lain lagi), tentu saya akan setuju dengan cara anda memakai goto.

    -Kurniady
    Anda benar, terima-kasih atas koreksinya.
    Last edited by nelvin; 06-04-2007 at 13:24.

  8. #18
    Join Date
    Feb 2005
    Location
    Bogor
    Posts
    603
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Rep Power
    20

    Re: Pemrograman yang hanya pemrograman



    nice post bro sangat membantu sekali infonya

  9. #19
    Join Date
    Jan 2005
    Posts
    908
    Thanks
    0
    Thanked 9 Times in 8 Posts
    Rep Power
    21

    Re: Pemrograman yang hanya pemrograman



    Wah wah wah ... jujur, ini yang selalu saya tunggu2
    keep it warm

    Regards,
    " A man's felicity consists not in the outward and visible blessing of fortune, but in the inward and unseen perfections and riches of the mind "

    thomas carlyle

    where i used to go when surfing :
    site1 site2 site3 ...


  10. #20
    Join Date
    Mar 2007
    Posts
    14
    Thanks
    0
    Thanked 1 Time in 1 Post
    Rep Power
    0

    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 dirasa masih kurang. Begitu banyak code OOP yang saya lihat, tetapi yang digunakan hanyalah syntax nya saja. Sedangkan esensi terpenting dari OOP nya sendiri justru tidak ada, tidak disadari, atau tidak dimengerti. Sehingga code nya tetap 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 be fixed easily is a showcase of lack of skill.)

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

    Mengapa OOP gagal diimplementasikan


    Mari kita mulai dengan pertanyaan mengapa OOP setelah sekian puluh 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 dengan pembahasan mengenai SYNTAX bahasa OOP, yang memang paling popular yaitu : Encapsulation, Inheritance, dan Polymorphism. Padahal ketiga hal ini merupakan implikasi dari teknik OOP, bukan esensi dari OOP, maupun the reason behind atau “why” teknik OOP sangat powerful. Tanpa mengerti “why” nya, kita tidak akan pernah tahu dengan tepat kapan ketiga hal tersebut seharusnya digunakan. Dan bahkan lebih parah lagi karena banyak esensi dari OOP yang tidak dicover oleh ketiga syntax tersebut, malah tidak dipergunakan. Jadi walaupun telah menggunakan OOP, coding nya tidak jauh berbeda dengan cara coding 30 tahun yang lalu.
    • Contoh yang digunakan hampir selalu menggunakan contoh paradigma keluarga buah-buahan, atau kendaraan, atau jenis-jenis binatang, tanpa menunjukkan secara gamblang kenapa sebuah teknik sangat powerful. Maksud saya gamblang adalah seharusnya ditunjukkan dengan sebuah angka sehingga tidak terbantahkan.
    Syntax OOP bukanlah esensi dari OOP

    Salah satu tujuan paling hakiki dari semua teknik pemrograman adalah bagaimana membuat program yang berjalan baik dengan waktu yang secepat-cepatnya. Atau dengan kata lain adalah produktifitas. Peningkatan produktifitas paling significant adalah pada saat pertama kali diciptakan bahasa tingkat tinggi. Dari tadinya kita harus mengetik berbaris-baris syntax bahasa assembly / mesin, atau bahkan puluhan syntax, cukup hanya digantikan hanya dengan satu-dua syntax bahasa tingkat tinggi. Ini jelas peningkatan produktifitas, karena jelas technical justification nya. Yaitu : misalnya 5 syntax menjadi 1 syntax, jelas terjadi peningkatan produktifitas sebesar 5 kali. (Perhatikan : ada angka yang menjadi basis untuk menjustifikasi ini lebih produktif.)

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


    Masalah nya adalah banyak programmer yang terpaku pada syntax dari object oriented, sedangkan produktifitas yang didapat dari bahasa object oriented JELAS bukanlah dari perubahan syntax prosedural menjadi object oriented. Coba perhatikan dua syntax ini, dimana yg pertama merupakan syntax prosedural, sedangkan yang kedua merupakan object oriented:
    • ResizeWindow(chartObject, …)
    • chartObject.ResizeWindow(…)
    Kedua syntax tersebut mempunyai jumlah karakter yang hampir sama. Sehingga jelas tidak ada peningkatan produktifitas dalam hal syntax seperti halnya perubahan dari bahasa assembly ke bahasa tingkat tinggi. Tentu menjadi jelas jika dikatakan kegunaan dari teknik / bahasa object oriented bukanlah sekedar perubahan syntax seperti di atas. Padahal inilah jawaban yang selalu saya dapatkan, mungkin 9 dari 10 jawaban, setiap kali saya bertanya ke seorang programmer mengapa object-oriented sangat powerful. Tidak heran jika akhirnya pemanfaatan object oriented tidak terlihat benefit nya jika digunakan oleh programmer dengan pemahaman yang serendah itu.

    Model yang sama juga terjadi dengan syntax inheritance dan syntax polymorphism, semuanya bisa direplace dengan syntax prosedural tanpa ada perbadaan jumlah karakter yg berarti. Inheritance bisa direplace dengan teknik data containment. Polymorphism apalagi, karena secara syntax hanya merupakan cara lain untuk mengidentifikasi sebuah function atau procedure. Jadi jelas syntax BUKAN lah keunggulan utama dari object oriented.

    Beberapa orang akan beragumen : dengan cara object oriented, syntax nya menjadi lebih jelas. Saya akan challenge dengan pertanyaan “seberapa banyak lebih jelas??”. Adakah kadar mengenai “lebih jelas” dari case di atas yang bisa dinyatakan dalam angka?? Bisakah ditunjukkan claim lebih jelas itu dengan angka seperti 10% lebih jelas atau 3000% lebih jelas?? Jika tidak bisa, alasan ini adalah alasan kabur yang dengan gampang dibantahkan, karena “lebih jelas” di sini hanya sekedar masalah preferensi. Dengan konsep technical justification dimana selalu harus ada angka atau sebuah postulat sederhana, argumen di atas yang sekedar berisi claim “lebih jelas” dengan sendirinya tidak berharga. Dan saya pribadi, diharapkan juga para pembaca, tidak mau menghabiskan waktu untuk berdebat mengenai hal-hal mengambang seperti ini. Lets kita fokuskan waktu yang sangat berharga kepada hal-hal yang lebih jelas seperti statement “peningkatan produktifitas 100 kali”. Sangat gamblang dan terang benderang karena ada angka “100” tersebut – atau whatever angka. Bahkan angka yang “hanya” “dua kali” pun masih jauh jauh lebih berharga dibandingkan argumen yang tidak mempunya angka atau technical justification.

    Jika pembaca masih setuju dengan saya, mari kita lanjut.

    Localization and Technical justification

    Oleh karena itu diperlukan sebuah pendekatan lain untuk mempelajari OOP. Yang dirasakan kurang selama ini adalah pembahasan mengenai “why” sebuah teknik OOP baik. Tanpa mengerti “why”nya, kita tidak mempunyai dasar yang cukup untuk meng-apply sebuah teknik. Dari menjawab “why” ini, ternyata selalu berujung kepada HANYA beberapa guidance sederhana, yang sangat practical untuk di-apply hingga ke level per baris code. Guidance ini disebut Localization. Selanjutnya tentu saja “why” Localization menjamin bahwa code yang mengikuti guidance nya merupakan code yang lebih baik? Localization sendiri dibuktikan dengan sebuah cara yang tidak terbantahkan seperti pembuktian sebuah persamaan matematika - yang kalaupun tidak possible, sedikitnya mendekati itu. Cara ini yang disebut sebagai Technical Justification.

    Technical justification yang dimaksud adalah sedikitnya harus mempunyai satu dari dua unsur berikut. Unsur pertama adalah : dinyatakan dengan sebuah angka seperti halnya membuktikan sebuah 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 ribu file. Unsur kedua adalah jika ternyata memang tidak bisa dinyatakan dengan angka, harus ada sebuah postulat bersama, atau sebuah definisi bersama, yang sangat sederhana sehingga dengan mudah bisa dijadikan dasar untuk membuktikan sebuah coding style adalah lebih baik – tidak terbantahkan. Sehingga simply kita akan berbicara programming style seperti halnya kita berbicara persamaan matematika yang tidak terbantahkan.

    Localization

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

    OOP diclaim bisa membuahkan code yang lebih rapih dan bug yang lebih mudah ditrace. Tetapi untuk bikin code yg rapih, bug mudah ditrace, tanpa OOP pun bisa dilakukan. So pertanyaan nya kenapa OOP bisa diclaim code nya lebih rapi dan bug nya mudah ditrace? Apakah ini hanya masalah preferensi atau adakah sebuah rumusan coding style yang bisa dijadikan pegangan? Kalau hanya preferensi, kita bisa salah, dan kalau diskusi pun menjadi debat kusir mengenai mana coding style yg lebih baik. Dari sekian banyak code-code OOP yg saya review, ternyata kebanyakan coding style yg dipilih memang hanya berdasarkan preferensi / intuisi - karena tidak pernah ada yg bisa menjelaskan dengan gamblang kenapa sebuah coding style yg dipilih lebih rapih, dan kenapa bug nya lebih gampang ditrace. Dan setelah direview menggunakan technical justification, ternyata memang sebagian besar programmer meng-apply teknik pemrograman dengan cara yang tidak tepat.

    Bahasa tingkat tinggi memberikan produktifitas dengan magnitude yang luar biasa. Seiring dengan meningkatnya produktitas, jumlah code yang ditulispun kembali menjadi luar biasa. Dan ini menimbulkan challenge baru. Kenapa? Karena simply otak manusia terbatas, sehingga tidak mungkin dalam satu waktu seorang manusia normal sanggup mengatasi kompleksitas dari jumlah code yang sangat banyak tersebut. Cara mengatasi kompleksitas tersebut tentu saja adalah dengan membagi program yang berukuran super besar tersebut menjadi bagian-bagian yang lebih kecil yang masih sanggup dihandle oleh otak manusia.
    Last edited by nelvin; 19-01-2012 at 12:50.


 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts