Hikmah Dari Upaya Contribute Ke Open Source

Sudah menjadi knowledge umum di internet kalau cara termudah untuk bekerja sama dengan orang-orang brilian di seluruh dunia adalah dengan bergabung ke open-source project mereka. Project-project open-source tertentu memang ada yang sarat dengan ilmu, dan Bombermaaan salah satunya.

Awalnya ngeliat bombermaaan dari game di liberkey, karena dulu waktu kecil suka bermain game itu, maka di download-lah dan dimainkan. Begitu ditekahui bombermaaan itu open source, iseng-iseng checkout source-code-nya, ngeliat to-do list-nya, mau mencoba implement team-mode.

And that turns out to be a good decision, ngeliat code-based-nya project bombermaaan, akhirnya sadar betapa bergunanya komentar kode yang konsisten dan extensive. Author-author sebelumnya seperti memulai coding dengan pseudocode, setelah rampung baru dicoding ke bahasa spesifik (C++). Pseudocode tersebut akhirnya menjadi komentar-komentar yang sangat membantu dalam pembacaan kode, penelusuran kode, dan tentunya dalam memahami apa yang terjadi pada kode.

Selama ini Saya berpikir bahwa naming variabel, method dan class yang baik cukup untuk membuat suatu kode nyaman dibaca. Namun setelah melihat kode bombermaan, hal tersebut saya sadari salah karena meskipun kode tersebut memiliki naming yang baik, komentar-komentar yang berupa pseudocode-nya lah yang paling membantu saya dalam memahami kode.

Saat ini sedang menunggu balasan author-nya untuk request agar mereka melihat hasilnya dan meminta feedback. Semoga lancar dan akhirnya kode dicommit, sehingga bisa dihitung telah benar-benar contribute kode ke open source project.
-------
Update: Author sudah me-reply, dia menyarankan untuk melakukan fork-ing terhadap project ini karena memang tidak ada aktivitas lagi di project ini dari original author-author-nya. Sayang sekali saya belum berpikir untuk memaintain suatu open source project. Berarti saatnya hunting open source project lain untuk berkontribusi. Ada ide?

Bahaya Overidable Method di Konstruktor

Lagi coding Java, nemu error Overridable method call in constructor. Jadi keinget dulu di c++ pernah ngalamin hal yang sama, semua OOP kyknya begitu deh, jadi pengen jelasin lebih detil.

Apa itu Overridable Method di Konstruktor?
Overridable Method adalah method pada suatu kelas yang dapat di override pada kelas turunannya. Umumnya hampir method public dapat di override.

Kenapa Overridable Method di Konstruktor berbahaya?
Katakan ada kelas A, yang pada konstruktornya memanggil method EchoClass(), isinya ngeprint A.
Kemudian ada kelas B, turunan kelas A, yang meng-override EchoClass(), yang isinya ngeprint B.
Katakan konstruktor B isinya kosong, dengan kondisi demikian, ketika kita meng-instansiasi kelas B, EchoClass yang ngeprint B tidak akan pernah muncul, yang muncul hanyalah ngeprint A.

err, berbahayanya dimana ya?
sebenernya ga bahaya sih kalo contoh diatas. Tapi pada umumnya, kenapa sampai EchoClass di override, itu pasti terdapat suatu maksud. Jika seorang perancang memang bermaksud menggunakan EchoClass dari Kelas Bapaknya, tentunya tidak akan repot-repot meng-override EchoClass. Ketika yang diharapkan dari menginstansiasi kelas B adalah memanggil EchoClass() yang ngeprint B, disinilah bahayanya muncul.
Coba kita ganti nama kelasnya, A menjadi OSHandler, B menjadi LinuxHandler, dan EchoClass menjadi InitializeClass(). Bisa saja seorang beranggapan ketika menginstansiasi LinuxHandler, berharap LinuxHandler.InitializeClass() yang dipanggil, padahal kenyataannya tidak demikian.

Wajar bahaya, orang ribet gitu kelas-kelasnya, coba bikin simpel pasti ga bahaya deh
yah, kalo bisa mengindari situasi kayak diatas, tentu bagus sekali.

Anggep emang kayak diatas deh kasusnya, solusinya gimana?
sederhananya, membuat Overridable Method menjadi Un-Overridable Method. Ini jalan pintasnya, meski terkadang tidak bisa semudah itu. Caranya paling mudah adalah dengan mem-private-kan method tersebut.

Tapi ya, ga pernah tuh gw ngalamin kasus gitu
Good for you then. unfortunately for me, gw malah udah 2 kali ngalamin.

Ada yang kurang jelas atau ingin tanya lebih dalam? tulis aja di comment ya, akan Saya jawab sebelum nambah post pastinya, thkyu.

Konsep OOP yang Terlupakan: Invariant

Waktu kuliah OOP (Object Oriented Programming), Saya diajarkan untuk men-private-kan variabel member sebuah kelas, untuk encapsulation bahasa kerennya. Tapi karena ga tau KENAPA perlu di buat private, akhirnya sering Saya declare public.

Ketika akhir kuliah, mulai kerasa manfaatnya di private-kan. Contoh paling jelas mungkin WAKTU. kelas WAKTU kurang lebih biasanya seperti ini:

class Waktu {

int Jam;

int Menit;

int Detik;

}

Jika Saya declare public variabel diatas, maka mungkin Object Waktu menjadi tidak valid. Maksudnya, adakah jam -1? adakah detik ke 77? adakah menit ke 60? tidak, karena Jam diantara 0 sampai 23, demikian juga dengan menit dan detik, yang memiliki batasan sendiri. Sejak ini, Saya terus secara konsisten mem-private-kan variabel member.

Setelah Saya bekerja, tiba-tiba sampai pada website ini, Saya tertarik dan melihat lihat lebih dalam. Lagipula, siapa yang tidak tertarik dengan materi kuliah MIT yang tersohor, hehe

Disana Saya baru tahu yang namanya Invariant. Invariant adalah sesuatu yang TRUE pada seluruh instance suatu kelas, dalam keadaan apapun instance tersebut.

Contoh pada kelas Waktu diatas, jika seluruh variabel di declare public, maka invariantnya adalah:

{

MIN_INTEGER <= Jam <= MAX_INTEGER,

MIN_INTEGER <= Menit <= MAX_INTEGER ,

MIN_INTEGER <= Detik <= MAX_INTEGER

}

berapapun nilai Jam, Menit dan Detik, pasti kondisi diatas akan tetap TRUE.

Namun tentunya invariant diatas tidak tepat, karena Jam sendiri antara 0..23, Menit dan Detik antara 0..59. Sehingga INVARIANT YANG BENAR untuk kelas Waktu adalah:

{

0 <= Jam <= 23,

0 <= Menit <= 59,

0 <= Detik <= 59

}

Tentu Saja Invariant diatas tidak tercapai dengan sendirinya. Disinilah peran dari men-declare variabel member private, agar Invariant dari kelas Waktu tetap terjaga.

Sayangnya, Invariant ini seringkali tidak se-explisit contoh Waktu diatas. Oleh karena itu, cocok sekali jika deklarasi suatu kelas ditambahkan dengan komentar mengenai Invariant-nya. Hal ini akan sangat membantu developer lain atau bahkan pembuat kelas tersebut untuk memahami suatu deklarasi kelas.

Meski Saya sendiri belom 100% menuliskan Invariant kelas-kelas yang Saya buat, hehe, Saya akan berusaha mengejar 100% tersebut. Sebaiknya begitu juga dengan Anda :)