OOP melengkapi teknik Prosedural,BUKAN BERBEDA.
1.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?
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.
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.
1.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.
1.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:
Biayanya bisa terjangkau oleh user.
Bug-nya tidak terlalu banyak, masih bisa diterima-lah (tidak ada aplikasi yg bug-free).
Berjalan sesuai dengan fungsi yang diinginkan oleh user.
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.
1.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.
1.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:
User butuh aplikasi komputer.
Aplikasi komputer = urutan instruksi.
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”.
1.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):
0105 (yang artinya taroh angka lima di register X).
0208 (yang artinya taroh angka delapan di register Y).
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.
1.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.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?
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.
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.
1.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.
1.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:
Biayanya bisa terjangkau oleh user.
Bug-nya tidak terlalu banyak, masih bisa diterima-lah (tidak ada aplikasi yg bug-free).
Berjalan sesuai dengan fungsi yang diinginkan oleh user.
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.
1.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.
1.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:
User butuh aplikasi komputer.
Aplikasi komputer = urutan instruksi.
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”.
1.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):
0105 (yang artinya taroh angka lima di register X).
0208 (yang artinya taroh angka delapan di register Y).
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.
1.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:
MoveX, 5
MoveY, 8
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:
Baca text.
Jika text = “MoveX” then
Output “01”
Baca text
Output text tsb (yaitu 05)
Goto nomor 1
Jika text = “MoveY” then
Output “02”
Baca text.
Output text tsb (yaitu 08)
Goto nomor 1
Jika text = “SumXY” then
Output “03”
Goto nomor 1
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.
1.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):
MoveX, 5
MoveY, 8
SumXY
Dan-seterusnya-seterusnya...
Sekarang cukup:
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.
1.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:
Banyak kumpulan dari code yang bisa digunakan di banyak tempat, susah digunakan.
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:
(masalah ringan) Waktu mau return dari fungsi repot sekali.
(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.
(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).
(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:
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.
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.
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.
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:
Goto JELEK! Pokoke program sing ana “goto” JELEK.
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.
Dikutip dari : http://netindonesia.net/forums/t/5892.aspx
