Belajar Menerapkan Object Oriented Programming (OOP)


Tidak dapat dipungkiri bahwa flowchart adalah cara paling alami untuk menggambarkan kode program karena komputer memang mengerjakan baris program secara berurut. Sebagai contoh, berikut ini adalah flowchart untuk menghitung nilai total untuk sebuah faktur:

Contoh Flowchart

Contoh Flowchart

Bila dibuat ke dalam program, akan terlihat seperti berikut ini:

LocalDate tanggal = LocalDate.now();
String nomorFaktur = "FA-001";
String[] produk = new String[]{"ProdukA", "ProdukB"};
int[] jumlah = new int[]{10, 20};
long[] harga = new long[]{1000, 2000};
long total = 0;
for (int i=0; i<produk.length; i++) {
   total += jumlah[i] * harga[i];
}

Salah satu kritik yang sering diberikan pada OOP adalah ia tidak menggambarkan alur eksekusi secara jelas. Namun, sebagai gantinya, ia memiliki sebuah keuntungan yang tidak dimiliki oleh metode prosedural seperti di atas. Bila dilihat sekilas, flowchart di atas berkaitan dengan faktur dan produk. Namun, faktur dan produk tidak tergambar secara jelas di flowchart. Bandingkan dengan UML Class Diagram berikut ini:

Contoh UML Class Diagram

Contoh UML Class Diagram

public class Faktur {
  String nomor;
  LocalDate tanggal;
  List<ItemFaktur> items = new ArrayList<>();

  public long total() {
      long hasil = 0;
      for (ItemFaktur item: items) {
          hasil += item.total();
      }
      return hasil;
  }
}

public class ItemFaktur {
  Produk produk;
  int qty;
  long harga;

  public long total() {
      return qty * harga;
  }
}

public class Produk {
  String nama;
  long hargaEceran;
}

Pada versi OOP, terlihat klasifikasi secara jelas. Letak kode program juga dipisah sesuai dengan klasifikasi yang telah ditentukan. Semakin rumit permasalahan yang dihadapi, metode OOP akan semakin berguna.

Apa beda class diagram (OOP) dengan ERD (tabel database)? Class diagram tidak menggambarkan penampungan data seperti pada ERD. Pada saat membuat ERD, fokus saya adalah menentukan struktur penyimpanan yang efisien. Pada saat membuat class diagram, fokus saya adalah melakukan klasifikasi permasalahan sehingga permasalahan menjadi lebih mudah dipahami dan diselesaikan.

Apa yang digambarkan oleh class diagram adalah kumpulan class yang saling berinteraksi. Class-class ini tentunya tidak bisa bekerja sendiri. Mereka harus direalisasikan dalam bentuk object, misalnya dengan kode program seperti berikut ini:

Faktur faktur1 = new Faktur(...);
faktur1.total();

Faktur faktur2 = new Faktur(...);
faktur2.total();

Alur eksekusi program tidak terlihat secara jelas di class diagram. Untuk itu, UML memiliki activity diagram yang mirip flowchart. Tapi diagram yang paling tepat untuk menggambarkan interaksi antar-class secara berurutan adalah sequence diagram. Sebagai contoh, objek untuk class Faktur akan diciptakan di memori pada saat tombol Simpan di-klik, seperti yang ditunjukkan pada diagram berikut ini:

Contoh UML Sequence Diagram

Contoh UML Sequence Diagram

public void simpan_click() {
   Faktur f = new Faktur();
   f.tanggal = datePicker.getDate();
   f.nomor = txtNomor.getText();
   f.items = tblItems.getItems();
   txtTotal.text = f.total();
}

Pada class diagram untuk domain model, saya tidak perlu menggambarkan class milik tampilan UI seperti form dan tombol. Setiap class yang ada di class diagram tersebut harus dapat bekerja tanpa terikat oleh UI atau database. Perhitungan total dan interaksi lainnya harus dapat bekerja, baik ada UI maupun tidak ada. Dengan demikian, objek untuk class Faktur tidak hanya bisa diciptakan oleh UI, tapi juga di unit test untuk pengujian otomatis dan sebagainya.

Seandainya saya memakai ORM seperti JPA, maka saya bisa menyimpan objek Faktur secara mudah ke database. ORM adalah framework yang akan menyimpan object ke tabel di database relasional secara otomatis. Alur eksekusi saat tombol Simpan di-klik kini akan terlihat seperti pada diagram berikut ini:

Menyimpan Ke Database

Menyimpan Ke Database

public void simpan_click() {
   Faktur f = new Faktur();
   ...
   txtTotal.text = f.total();
   dao.simpan(f);
}

Sekali lagi, saya tidak memasukkan class DAO ke dalam rancangan class diagram domain. Ingat bahwa domain class yang ada harus dapat bekerja baik ada database maupun tidak ada. Kode program pada UI (seperti saat tombol di-klik) dan kode program pada DAO (untuk menyimpan ke database) disebut sebagai berada pada layer terpisah. Mereka bukan bagian dari permasalahan utama (inventory, akuntansi, restoran, dsb). Kode program pada layer yang berbeda bisa ditulis secara terpisah setelah domain class selesai dirancang.

Pada faktur, biasanya nomor perlu dihasilkan secara otomatis. Bila kode program untuk menghasilkan nomor secara otomatis tidak berada di class diagram, kemungkinan besar ia ada di database (dalam bentuk auto increment primary key atau trigger) atau di UI. Ini adalah sesuatu yang tidak disarankan! Sebagai contoh, bila terletak di UI, ia akan terlihat seperti berikut ini:

public void simpan_click() {
   Faktur f = new Faktur();
   int nomorTerakhir = dao.findFakturCount();
   f.nomor = 'FA-' + nomorTerakhir;
   ...
}

Kode program untuk menghasilkan nomor faktur adalah bagian dari permasalahan bisnis. Misalnya suatu saat nanti pengguna bisa menginginkan format yang berbeda. Kode program seperti ini juga harus reusable. Dengan demikian, ia seharusnya tergambar dalam class diagram. Oleh sebab itu, saya bisa membuat repository seperti yang terlihat pada gambar berikut ini:

Memakai Repository

Memakai Repository

Saya meletakkan kode program yang menghasilkan nomor berurut pada method buat() di FakturRepository. Sekarang, alur interaksi class menjadi berikut ini:

Sequence Diagram Setelah Penggunaan Repository

Sequence Diagram Setelah Penggunaan Repository

Kode program yang memakai class akan terlihat seperti:

public void simpan_click() {
   Faktur f = new Faktur();
   f.tanggal = datePicker.getDate();
   f.items = tblItems.getItems();
   fakturRepository.buat(f);
   ...
}

Kesimpulan:

  1. Terlihat bahwa OOP tidak menunjukkan alur eksekusi program secara jelas. Walaupun demikian, ia sangat mendukung pemodelan yang mempermudah developer dalam mengelola kode program. Kode program prosedural lebih mudah ditelusuri tapi rentan menyebabkan kebingungan di kemudian hari terutama bila cakupan kode program semakin luas.
  2. Kode program pada domain class harus bisa dikerjakan tanpa terikat pada UI, database, dan sebagainya. Ini menimbulkan pembagian secara horizontal yang disebut layer dimana setiap layer memiliki tugas-nya masing-masing yang tidak memiliki sangkut paut dengan internal di layer lain. Contoh layer yang umum dijumpai adalah presentation layer untuk menampilkan GUI dan persistence layer untuk menyimpan object ke database.

Perihal Solid Snake
I'm nothing...

One Response to Belajar Menerapkan Object Oriented Programming (OOP)

  1. Ping-balik: Belajar Memakai Object Di OOP | The Solid Snake

Apa komentar Anda?

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: