I Prefix dan Impl Suffix

1. Konvensi Penamaan Interface dan Implementasi

• Pola umum:

  • Beberapa developer menggunakan I prefix untuk interface (contoh: ITaxCalculator).

  • Beberapa menggunakan Impl suffix untuk implementasi (contoh: TaxCalculatorImpl).

• Masalah dengan konvensi ini:

  • Redundan: I atau Impl tidak menambah kejelasan karena bahasa pemrograman sudah membedakan interface dan implementasi.

  • Tidak longgar terhubung (loosely coupled): Perubahan di interface mengharuskan perubahan di implementasi.

2. Kelebihan dan Kekurangan Penggunaan Interface untuk Semua Implementasi

• Kelebihan:

  • Memudahkan mocking dan penggantian implementasi saat testing.

  • Berguna di bahasa statically typed (Java, Go) di mana substitusi objek tidak mudah.

• Kekurangan:

  • Over-engineering: Tidak semua komponen memerlukan interface jika hanya punya satu implementasi.

  • Kode test jadi rumit: Mock berlebihan membuat test sulit dipelihara.

3. Masalah dalam Pendekatan Testing yang Kurang Baik

• Testing dianggap "second-class citizen":

  • Developer sering fokus ke implementasi dulu, baru memikirkan testing belakangan.

  • Akibatnya, dibuat banyak interface hanya untuk mempermudah mocking, bukan karena kebutuhan desain.

• Mocking yang berlebihan:

  • Mock sebaiknya hanya digunakan untuk:

    1. Kode yang terlalu kompleks/lambat untuk di-test.

    2. Operasi IO/network yang tidak stabil atau sulit direproduksi.

  • Terlalu banyak mock membuat test rapuh (perubahan logika mengharuskan update semua mock).

4. Solusi yang Lebih Baik

• Isolasi kode yang sulit di-test:

  • Pisahkan logika bisnis (deterministik) dari operasi IO (network, file, system call).

  • Kode non-IO lebih mudah di-test karena perilakunya dapat diprediksi.

• Hindari interface yang tidak diperlukan:

  • Jika hanya ada satu implementasi, pertimbangkan untuk tidak membuat interface.

  • Gunakan interface hanya jika benar-benar dibutuhkan (misal: untuk dependency injection atau polymorphism).

5. Filosofi Pengembangan Software yang Lebih Baik

• Software development adalah proses iteratif:

  • Awalnya boleh menggunakan I/Impl jika belum ada solusi lebih baik.

  • Seiring waktu, perbaiki struktur kode (gabung atau pecah komponen sesuai kebutuhan).

• Kode yang baik terus diperbaiki:

  • Setiap engineer menulis kode "jelek" di awal, tapi engineer yang baik terus melakukan refactor.

Kesimpulan

• Hindari I prefix dan Impl suffix kecuali benar-benar diperlukan.

• Jangan buat interface untuk semua hal—gunakan hanya saat ada multiple implementations atau kebutuhan testing yang spesifik.

• Fokus pada testing yang efektif:

  • Minimalkan mocking, isolasi kode IO, dan prioritaskan test pada logika bisnis.

• Terus perbaiki kode:

  • Desain ulang komponen seiring berkembangnya sistem.

Dengan pendekatan ini, kode menjadi lebih bersih, mudah dipelihara, dan siap untuk pengembangan jangka panjang.