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

  • #16
    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
    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


    error:


    }

    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




    }

    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

    Comment


    • #17
      Re: Lanjutan...

      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, 13:24.

      Comment


      • #18
        Re: Pemrograman yang hanya pemrograman

        nice post bro sangat membantu sekali infonya

        Comment


        • #19
          Re: Pemrograman yang hanya pemrograman

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

          Regards,

          Comment


          • #20
            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, 12:50.

            Comment


            • #21
              <lanjutan...>

              Teknik yang memecah-belah kompleksitas menjadi sub-bagian yang bisa dihandle oleh otak manusia,adalah teknik umum yang digunakan di berbagai bidang apapun. Yang karena nya saya sebut saja sebagai localization. Lhoooww??? Kok bukan object-oriented??? Object oriented memang mempunyai fitur yang lebih banyak dibandingkan hal yang lain, sehingga by-default object oriented menjadi lebih popular. Tetapi perlu diingat bahwa object oriented ada karena kebutuhan melakukan localization. Sehingga tanpa memahami localization terlebih dahulu, tentu tidak akan dapat menerapkan object oriented dengan maksimal.

              Encapsulation, inheritance, dan polymorphism, merupakan pengembangan dari teknik-teknik pemrograman yang sudah dimulai sejak ilmu programming tercipta, yang disempurnakan dengan bahasa tingkat tinggi, disempurnakan dengan prosedural, hingga yang sekarang disebut object oriented, tetapi dasar konsep nya tidak pernah berubah yaitu untuk menerapkan localization. Sayang dengan semakin banyaknya teknik, kita cenderung melupakan esensi “why” teknik tersebut diciptakan, sehingga pengaplikasian nya menjadi salah dan benefit nya menjadi hilang.

              Localization guidance

              Dari mengamati impact penerapan OOP yang betul berdasarkan technical justification, ternyata sebagian besar teknik OOP, termasuk tool-tool yang ada, berujung kepada salah satu dari empat bentuk code berikut. Keempat bentuk code berikut inilah yang disebut sebagai Localization guidance. Mereka adalah sebagai berikut:

              L1 : Localize 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 baris code diubah menjadi 10 baris of code, berarti 100 kali lebih sederhana. Ini jelas something very very significant.

              L2 : Yang saling terkait dilocalize 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, dibandingkan jika harus memahami satu class saja. 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 un-localize 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 variable. Ini menjamin variable-variable yang sudah kita kumpulkan jadi satu dengan teknik L2 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 di level setiap baris code.

              Perhatikan semuanya berisi aturan terang benderang tentang apa yang harus dilakukan untuk setiap case, exactly step by step, di level setiap baris 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.

              Jika bahkan programmer terbaikpun hanya sanggup menebak dengan ketepatan 10%, mengapa buang waktu dengan mencari-cari encapsulation / abstraction terlalu dini?? Apalagi di saat kita baru mulai berlatih. Dengan localization, teknik langsung diapply di level code by code. Bottom-up sehingga 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 itu, 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 ).

              Reflex

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

              Hanya jika kita bisa menjustifikasi sebuah coding style TIDAK berdasarkan preferensi, barulah kita bisa membangun skill OOP kita. Kenapa begitu? Skill hanya bisa dibangun dengan dilatih. Melatih hal yang salah, hanya membuat kesalahan kita menjadi perfect. Preferensi tidak memberikan guidance mana yang salah dan benar. Sebaliknya technical justification yang gamblang dan terang benderang, dan dalam banyak case dinyatakan dalam angka yang terang benderang, akan sangat jauh jauh lebih menjamin bahwa kita tidak berlatih hal yang salah.

              Errhh... berlatih?? Ya seharusnya jelas bukan bahwa skill harus dilatih. Akan tetapi yang terjadi di dunia programming (dan untung nya juga terjadi di dunia martial art), adalah justru sebaliknya. Orang cenderung mengumpulkan teknik, bukan melatih teknik tersebut.

              Berbeda dengan pandangan kebanyakan pandangan programmer yang kurang berpengalaman, atau para teoritis / pengamat pemrograman yang hanya pernah juggling beberapa baris code untuk contoh artikel, tetapi tidak pernah berlatih pemrograman secara real, selalu beranggapan bahwa programming bisa dikonseptualkan sejak awal. Well konseptor yang paling berpengalaman di dunia pun paling banter hanya sanggup mencapai 10% dari design aplikasi. Sisanya baru bisa ditemukan pada saat programming dilakukan. Tanpa pernah berlatih, kita tidak akan mempunyai kepekaan terhadap pola-pola code yang dihasilkan, yang sepintas lalu hanya seperti random, sehingga miss opportunity untuk menerapkan konsep yang bagus. Bahkan konsep yang paling sederhana / esensi seperti Localization pun bisa luput dari pandangan (apalagi konsep turunan dari localization yang lebih kompleks seperti object oriented). Karena itu tidak ada cara untuk meningkatkan skill programming adalah dengan mengenali banyak, sebanyak-banyaknya aplikasi dari sebuah teknis, dan terus berlatih seperti itu, sampai mempunyai kepekaan terhadap pola-pola yang ditemukan pada saat programming. Berlatih sampai daya reflex nya terbentuk.

              Karena itu pula saya sangat against kebiasaan yang memberikan contoh pengaplikasian dengan konsep abstrak yang lain. Ini hanya membuat orang tenggelam dalam lautan teknik dan kehilangan awareness terhadap esensi dari teknik. Contoh aplikasi haruslah dalam bentuk seperti persamaan matematika, yang dalam kasus ini harus dengan gampang ditunjukkan dengan code secara gamblang, yang kemudian bisa dihitung 1-2-3 dengan mudah... that is contoh yang memenuhi kriteria technical justification.

              Bagaimana berlatih / menerapkan Localization

              Langkap pertama adalah JUSTRU kita tidak perlu (tidak boleh) terlalu memikirkan terlalu dini mengenai encaps, inherit, poly, etc2 konsep OOP yg lebih abstract, tetapi fokus saja terlebih dahulu kepada struktur code yg real. Caranya gampang, yaitu fokus aja ke aplikasi yang sedang kita buat sesuai dengan apa yang natural menurut kita, tidak perlu dipikirkan struktur nya sudah baik atau belum, tidak perlu memikirkan apapun, just code exactly seperti yang kita pikir ( btw lebih fun bukan? ).

              Setelah code sudah terbentuk sebagian, tidak perlu terlalu banyak code, misalnya sudah dibuat sekitar 10 fungsi, reviewlah berdasarkan Localization guidance. Apakah ada dari code kita yang kurang sesuai, rubah code nya supaya sesuai dengan Localization guidance. Caranya bagaimana? Sesuai dengan teknik2 yang available di language masing-masing yang kita gunakan.

              Nanti secara natural, akan terlihat bagaiman teknik2 encaps, inherit, poly, etc, diaplikasikan untuk mencapai bentuk yg disuggest oleh Localization tsb. Biasakan terus seperti itu sampai itu menjadi reflex. Menjadi reflex artinya pada waktu construct code hasilnya sudah langsung semakin mendekati struktur code seperti yg diguide oleh Localization.

              Yang agak susah di awal adalah melihat bentuk2 mana yang perlu di-“Localization”-kan. Ini yang biasanya butuh mentor atau buku. ( Sayang nya buku nya belum tersedia ada )

              Dengan cara di atas, “why” nya menjadi jelas. Yaitu “why” menggunakan syntax2 encaps, inherit, poly, dan syntax2 yang lain? Yaitu untuk mencapai bentuk Localization. “why” perlu bentuk Localization? Karena technical justification yang disebutkan di setiap teknik Localization tsb.


              Penutup

              Penjelasan teknik-teknik localization di atas begitu sederhana, sehingga kita merasa ah begitu gitu saja. Tetapi coba Anda buka code Anda sendiri, analyze dengan teknik2 localization di atas, 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 won’t be a fighter by just reading and talking. Just code it, and show your code blatlantly.


              Happy programming!
              Last edited by nelvin; 19-01-2012, 12:49.

              Comment


              • #22
                Re: <lanjutan...>

                wah...dah ampir 4 taon dilanjut lagi thread nya...g ampe lupa pernah baca ini ...tp emang bahasan nya bagus sih.

                jujur g kuliah IT..meski lulus IPK lmyn...tp soal OOP ini kgk pernah ngerti implementasi nya kyk apa..di kuliah cm diajarin class kendaraan..diturunin jadi class Mobil & class Truk...cape deh.

                seharusnya diajarin nya dengan contoh kasus kyk yg dibahas disini. baru pas kerja & koding aplikasi agak besar...baru deh kerasa harus implementasi dmana nya..meski itupun blm tentu bener.

                btw...thread di tetangga : http://www.kaskus.us/showthread.php?t=11760542
                pembahasan nya mirip & lebih hot (mgk programmer yg nongkrong di kaskus lbh banyak dari di chip).. dari kedua thread ini bs banyak blajar.

                klo yg dimaksud dengan Interface itu apa ya?msh blm mudeng

                Comment


                • #23
                  Re: Pemrograman yang hanya pemrograman

                  pembahasan di sini dan di kaskus saling melengkapi.
                  thx to brought " this thing " up again @micky very helpfull.
                  dan seharusnya kita di sini juga lebih banyak membahas selayak ini daripada membahas begitu banyak coding, yg bahkan yang bertanya pun masih belum paham dari apa yang ditanyakan sebenarnya, dan yang menjawab hanya sekedar menjawab dari apa yang ditanyakan ( that's not healthy tho .. and boring !! )

                  mengenai pendekatan bottom-up akan membentuk code secara alami lebih akurat dan tepat guna seperti @nelvin bahas di atas,,memang seperti itu seharusnya. Memang dengan cara seperti itu control thd code akan lebih kuat terhadap pencapaian hasil akhir dari development. Keterbiasaan dgn maksud untuk menulis code dengan cepat sebagai sebuah solusi, justru menutupi pikiran dari gambaran besar yang seharusnya dibangun dengan detil. Dan memang, untuk implementasi selayak yang @nelvin bahas akan memerlukan waktu yang cukup panjang tergantung besarnya framework yang akan dikembangkan,,namun kesudahannya akan sangat membantu diri sendiri.

                  Hmm,,mengenai localization sebagai esensi dari OOP ? Iya, saya setuju

                  Comment


                  • #24
                    Re: <lanjutan...>

                    Originally posted by mickwijaya View Post
                    wah...dah ampir 4 taon dilanjut lagi thread nya...g ampe lupa pernah baca ini ...tp emang bahasan nya bagus sih.

                    jujur g kuliah IT..meski lulus IPK lmyn...tp soal OOP ini kgk pernah ngerti implementasi nya kyk apa..di kuliah cm diajarin class kendaraan..diturunin jadi class Mobil & class Truk...cape deh.

                    seharusnya diajarin nya dengan contoh kasus kyk yg dibahas disini. baru pas kerja & koding aplikasi agak besar...baru deh kerasa harus implementasi dmana nya..meski itupun blm tentu bener.
                    Yg paling fun dan paling bener, itu langsung tancap coding aja Bro. Ide apa yg ada di pikiran langsung kerjain aja. Gak usah pusing sama konsep2 ini itu dulu. Langsung tancep. Nah nanti pasti ketemu problem, cari solusinya, dan cari cara gimana supaya problem seperti ini tidak terjadi lagi. Bisa mikir sendiri, bisa juga tanya. Dari sini baru langsung progress kemampuan coding nya.

                    Originally posted by mickwijaya View Post
                    btw...thread di tetangga : http://www.kaskus.us/showthread.php?t=11760542
                    pembahasan nya mirip & lebih hot (mgk programmer yg nongkrong di kaskus lbh banyak dari di chip).. dari kedua thread ini bs banyak blajar.
                    Thread ini ngawur. Ini tipikal orang yg waktu coding terlalu banyak aturan sendiri - dan lupa esensi coding. Normak Syndrome ini namanya. Coding should be fun.

                    Comment


                    • #25
                      Re: Pemrograman yang hanya pemrograman

                      Originally posted by positive+ View Post
                      mengenai pendekatan bottom-up akan membentuk code secara alami lebih akurat dan tepat guna seperti @nelvin bahas di atas,,memang seperti itu seharusnya. Memang dengan cara seperti itu control thd code akan lebih kuat terhadap pencapaian hasil akhir dari development. Keterbiasaan dgn maksud untuk menulis code dengan cepat sebagai sebuah solusi, justru menutupi pikiran dari gambaran besar yang seharusnya dibangun dengan detil. Dan memang, untuk implementasi selayak yang @nelvin bahas akan memerlukan waktu yang cukup panjang tergantung besarnya framework yang akan dikembangkan,,namun kesudahannya akan sangat membantu diri sendiri.
                      bottom-up ini diperlukan utk membentuk intuisi kita, intuisi yang sesuai dengan akal sehat tentunya. ini yang membedakan dengan top-down yang sering memberikan ilusi salah - terutama utk yang belum berpengalaman. pada saat kita aktual coding, tidak ada batasan, baru bottom-up, top-down, campur, whatever, lets do semua yg paling cocok, gak ada aturan yg baku utk ini. dan memang jangan kebanyakan aturan, karena coding supposed to be very fun.

                      Originally posted by positive+ View Post
                      Hmm,,mengenai localization sebagai esensi dari OOP ? Iya, saya setuju
                      sip.

                      Comment

                      Working...
                      X