Tuesday, November 30, 2010

Untuk Apa Bikin Method?

Saya pernah ditanya "Untuk apa bikin method?" baru-baru ini. Setelah lama berpikir, akhirnya menemukan jawaban yang keren (setidaknya untuk level Saya).

Jawabannya adalah untuk me-manage complexity.

Bagi yang baca buku Code Complete, pasti kenal istilah manage complexity. Bagi yang tidak, read on, but beware, this is a quite long post.

Misalnya, Saya diminta oleh dosen untuk bikin program baca file X, tulis isinya ke layar, dan save isinya ke file Y. katakan Saya masih pemula, belum tau cara baca file X, belum tau tulis ke layar, belum tau cara tulis ke file Y.
Tapi Saya diminta untuk menulis programnnya, saat itu juga. Dengan kondisi seperti ini, kira-kira jawaban Saya akan begini:


int main(int argc, char** argv) {
bacaFileX();
tampilkanIsiFileX();
tulisIsiFileXkeY();
}

Tugas dari dosen tadi jelas, Saya punya tiga concern/urusan/isu yang sebenarnya berbeda satu sama lain. 1 baca file, 1 tampilin ke layar, 1 tulis file. Kalo semua-nya digabungin, kode function main pasti akan panjang, selain itu, 3 concern tersebut menjadi satu. Sayangnya, Saya sedikit kesulitan memfokuskan pekerjaan jika dalam 1 method, terdapat lebih dari 1 concern.

di jawaban atas, terdapat total 4 method, masing-masing dengan concern yang berbeda:
  • 1 untuk mengurusi bagaimana cara program Saya memenuhi tugas dari dosen
  • 1 bagaimana cara baca file
  • 1 bagaimana cara tulis ke layar
  • 1 bagaimana cara tulis ke file
jadi ketika Saya melihat function main, concern Saya adalah apakah program dapat memenuhi tugas dosen. Ketika Saya liat bacaFileX(), concern-nya adalah bagaimana membaca file, dan HANYA BACA FILE. disini tidak memikirkan bagaimana cara tulis ke layar, gimana cara tulis ke file. Itu lain persoalan, sehingga tidak perlu. Dengan googling, akhirnya didapatkan cara baca file dengan C++. Di-implementasikanlah method tersebut.

Namun jika algoritma main tetap seperti diatas, isi File X hanya didapat didalam bacaFileX(), sedangkanyang dibutuhkan adalah isinya untuk ditampilin ke layar dan tulis ke file lain. Oleh karena itu, program utama perlu diubah menjadi demikian:

int main(int argc, char** argv) {
char* isiFileX = bacaFileX();
tampilkanIsiFileX();
tulisIsiFileXkeY();
}

dengan begitu, didapatlah isi file X.

kemudian berpindah ke tampilkanIsiFileX(). nah, disini dilakukan googling, akhirnya ditemukan cara menulis ke layar. Namun pas diimplementasi, didalam tampilkanIsiFileX(), perlu dilakukan pembacaan isi file. Dan ini jadinya menyalahi untuk concern tidak bisa lebih dari satu, oleh karena itu perlu diubah menjadi seperti ini:

int main(int argc, char** argv) {
char* isiFileX = bacaFileX();
tampilkanKeLayar(isiFileX);
tulisIsiFileXkeY();
}

kemudian berpindah ke tulisIsiFileXkeY(). concern ini mirip dengan tampilkan ke layar, diperlukan pembacaan isi file x dulu, sehingga menyalahi aturan 1 concern. Oleh karena itu, perlu diubah menjadi seperti ini:

int main(int argc, char** argv) {
char* isiFileX = bacaFileX();
tampilkanKeLayar(isiFileX);
tulisKeFileY(isiFileX);
}

akhirnya programnya selesai.

Keuntungannya managing complexity yang baik dengan maksimal 1 concern/method itu antara lain:
  • kode lebih mudah dimengerti. Dengan cuma 1 concern, biasanya Saya akan lebih mudah mengerti kode yang sudah lama tidak Saya lihat.
  • Biasanya Kode per function/procedure jadi lebih pendek. Kalo Saya pribadi, kode 1 method sebaiknya ga lebih dari 30 baris. Selain keliatan dari atas sampai bawah, lebih gampang dibaca juga karena tidak panjang.
  • Yang paling penting, jika ada perubahan, lebih mudah untuk diadopsi dan diberlakukan. Pada contoh diatas, jika dosen meminta file tersebut bukan di lokal namun di internet, maka hanya 1 method yang perlu berubah.
Ada yang bilang juga yang demikian disebut juga dengan abstraksi. Mungkin teknik diatas adalah teknik abstraksi, namun Saya ingin lebih menekankan pada tujuan diberlakukannya abstraksi, yaitu tetap untuk me-manage complexity.
Nah, bagaimana dengan anda, Untuk apa anda bikin method?

No comments:

Post a Comment