1. Tidak paham tentang konsep OOP

Java bukan murni bahasa pemrograman berorientasi Objek (OOP)

Apaa..? Benarkah itu ?

Ya benar, karena :

  1. Ada tipe data primitif yang bukan objek, seperti int, boolean, long, dll
  2. Ada fasilitas static yang memungkinkan kita mengakses fungsi tanpa harus instansiasi objek, misalnya Math.max(a,b). Fungsi static ini bisa diakses tanpa instansiasi object Math.
Lantas apa Java masih OOP ?

Masih, karena OOP nya di mindset/paradigma nya.

Java dibuat dengan paradigma/ mindset pemrograman berorientasi objek. Disana ada konsep Encapsulation, Inheritance, Polymorphism, dll. Itu sepertinya cukup untuk membuat Java dianggap sebagai bahasa berorientasi Object. Tetapi yaa itu , masih ada tipe data primitif dan akses static seperti yang disampaikan di atas.

Karena didesain menggunakan pendekatan Object, maka banyak fitur-fitur yang dioptimasi untuk mendukung hal tersebut.

Dengan fitur OOP diatas, memaksa Software Engineer untuk memodelkan masalah dengan perspektif kata benda. Tidak heran kalau kita lihat contoh tutorial Java, akan menggunakan contoh kata benda.

Misalnya :

  1. Class/Object Mobil terdiri dari mesin, setir, lampu, punya attribute jalan atau berhenti.
  2. Class/Object Rumah terdiri dari pintu, fondasi, jendela, dll.

Bahkan, untuk kata kerja pun yang bersifat fungsional, kita diajarkan untuk menggunakan kata benda.

Contoh :

  1. untuk melakukan validasi, kita akan membuat class/object Validator, dan kemudian memanggil fungsi validate().
  2. untuk melakukan ekstraksi data, kita akan membuat class/object Extractor, dan kemudian memanggil fungsi extract()
Kesimpulan

Object adalah komponen utama dalam Java. Objek adalah first-class nya bahasa pemrograman Java. Dan fitur-fitur dalam Java berlandaskan atas fakta ini. Sehingga kalau kita tidak memahami konsep OOP, maka entah kita akan kehilangan fitur nya atau optimasi tidak akan tercapai.

Lalu kemudian…

Ya memodelkan persoalan yang dihadapi di Java sebaiknya memakai pendekatan objek.

Tapi sekarang Java juga bisa pakai fitur fungsional juga kan ?

Iya tentu saja, memodelkan persoalan dengan pendekatan lain seperti fungsional, deklaratif, prosedural, atau imperatif tetap diterima asalkan sesuai dengan porsinya. Dan itu sudah difasilitasi di Java Functional.

Ketika kebutuhan solusinya sederhana, kita bisa menggunakan paradigma prosedural atau imperative. Akan tetapi kalau solusi dari persoalan ternyata rumit dan kompleks, maka pergunakanlah fasilitas OOP dari Java, termasuk didalamnya Fungsioal java yang didalamnya sebenarnya masih memakai pendekatan OOP yang dibungkus/wrapped.

2. Penggunaan library tanpa peduli detailnya, termasuk pre, post, dan exception.

Tiap library (.jar file) mempunyai dokumentasi yang bisa dibaca.

  1. Ada fungsi yang mensyaratkan pre-requisites yang mesti dipenuhi dahulu.
  2. Ada yang melakukan perubahan status/state secara implisit/tidak perlu diketahui oleh si pemanggil fungsi.
  3. Ada yang melakukan operasi komputasi berat atau menulis ke perangkat disk.
Saran ..

Mengetahui dan membaca Java Doc dari library yang kita gunakan di aplikasi java adalah hal penting sebelum menggunakannya. Minimal kita bisa lebih peduli dan tahu dengan apa yang dilakukan oleh fungsi tersebut. Apalagi kalau ada catatan tertentu yang sangat berpengaruh terhadap jalannya aplikasi kita seperti thread safe, deprecated, dll.

3.Tidak membuat unit test.

Seringkali dengan alasan deadline atau tenggat waktu pengerjaan yang sempit, Software Engineer tidak membuat unit test untuk code yang telah dibuatnya.

Aplikasinya mungkin tetap jalan, tetapi kita tidak yakin 100%.

Membuat unit test memang butuh waktu, namun sepadan dengan waktu yang dibutuhkan ketika memperbaiki bug disebabkan karena luput dari unit test.

Unit test biasanya tidak hanya meliputi logic utama dari sebuah aplikasi, tetapi kemungkinan bug-bug kecil yang luput dari perhatian kita waktu membuat aplikasi. Tetapi biasanya hal remeh temeh dan kecil-kecil inilah yang bisa menghabiskan waktu berharga kita. (#eeeaaaaaa)