Yang engkau bisa lihat adalah tampilan luar dari orang lain.

Sementara isi dalam hati dan diri orang lain tidaklah dapat engkau selami.

– The barks


Pendahuluan

Coding to Interface, Not to implementation

Istilah ini sering kita dengar ketika melakukan aktifitas coding secara Object Oriented Programming (OOP).

Ini sebenarnya konsep yang secara teknikal melakukan hal sbb :

  • Buat sebuah class interface.
  • Buat sebuah class implementasi dari interface diatas.
  • Buat class lain yang menggunakan interface diatas.
  • Gunakan method dari interface tadi daripada menggunakan class yang mengimplementasikannya.

Bingung.. ??

Ok, kita coba lihat contohnya :


Buat sebuah Interface, sebagai berikut :

public interface InterfaceA {
   void method1();
}

Buat sebuah class Implementasinya, sebagai berikut :

@Slf4j
@Component
public class ImplementasiA implements InterfaceA {

   void method1() {
      log.info("Method1 dipanggil");    
   }
}

Buat sebuah class Service sebagai penggunanya, sebagai berikut :

 1@Slf4j
 2@Service
 3public class ServiceA {
 4
 5   @Autowired
 6   private InterfaceA interfaceA;
 7
 8   public void service1() {
 9     interfaceA.method1();
10   }
11}

Kalau kita lihat di line 6, maka kita bisa melihat bahwa kita melakukan Autowired terhadap InterfaceA, dan bukan terhadap ImplementasiA .

Padahal kita tahu bahwa code nya yang kita buat sebenarnya berada di class ImplementasiA.

Tetapi kita tetap menggunakan InterfaceA di waktu deklarasi attribute dari ServiceA

Inilah yang disebut sebagai Coding to Interface, not to Implementation.


Kenapa kita tidak pakai @Autowired ImplementationA saja ?


Misalnya begini :

 1@Slf4j
 2@Service
 3public class ServiceA {
 4
 5   @Autowired
 6   private ImplementationA implementationA;
 7
 8   public void service1() {
 9     implementationA.method1();
10   }
11}

Secara teknis bisa saja toh..

Dan tentunya programnya juga jalan.

Dan sepertinya juga lebih jelas dari sisi membaca codenya sebenarnya pointing ke class yang mana.

Tetapi secara filosofis, ada yang kurang..

Kurang dimana ?

Kurang di sisi abstraksi program.

Kalau di sebuah perusahaan, maka abstraksi program ini masuk ke Tangible asset.

Sesuatu yang tidak kelihatan langsung, akan tetapi sangat baik untuk keberlangsungan perusahaan nantinya.

Aaah..lebay luh..

Eh tapi benar..

Coding to Interface, not to Implementation merupakan menjaga sisi Tangible dari sebuah program.

Lebih tepatnya adalah :

Loosely Coupling

Loosely Coupling

Loosely Coupling mengacu kepada :

  • Ketergantungan/asosiasi yang lemah antara sebuah class dengan class lainnya.
  • Interaksi satu object dengan object lain dengan definisi attribute seminimal mungkin.

Oleh karena itu muncullah istilah Interface, Service, encapsulation, dll.

Loosely Coupling ini berupaya meminimalkan Coupling / Ikatan , jadi bukan berarti No Coupling

Tetap ada ikatan, tapi longgar..

Cieee.. ikatan kok longgar-longgar saja., eratin dong..

Upss., ini kita membahas yang berbeda yaa..

Iya benaar..

Kalau kita lihat contoh di atas yang langsung memakai class ImplementationA, maka permasalahannya adalah :

  • Ketika kita ingin membuat tambahan implementasi baru yang berbeda, maka kita hanya perlu menambah class baru yang implements interfaceA, dan melakukan injection terhadap class yang baru saja.
  • Mudah mengganti-ganti class konkrit nya diwaktu build-time ataupun runtime.
  • Lebih bersih ketika kita membuat unit test, karena yang kita test adalah kontrak di interface nya saja.
  • Lebih fleksibel dalam hal ekstensibilitas dari program. Misalnya class implementasinya berubah banyak dan menambahkan dependensi lainnya.
  • dll.

Tetapi tentunya ada juga yang berpendapat bahwa :

  • Kalau hanya cuma satu implementation saja, ngapain membuat sebuah class interface juga ?
  • Kalau programnya tidak berkembang lagi, ngapain bikin interface..

Ok..ok.., itu alasan yang cukup masuk akal…

Akan tetapi tentunya Coding to Interface, Not To Implementation adalah Best Practice saja.

Jadi silahkan diikutin, silahkan tidak..

Sesimple itu..