Bagaimana Injeksi Dependensi Meningkatkan Testabilitas dan Modularitas

Apa Arti Injeksi Dependensi (Tanpa Jargon)

Injeksi Dependensi (DI) adalah ide sederhana: alih-alih sebuah potongan kode membuat hal-hal yang dibutuhkannya, Anda memberikannya dari luar.

"Hal-hal yang dibutuhkannya" itu adalah dependency—misalnya koneksi basis data, layanan pembayaran, jam, logger, atau pengirim email. Jika kode Anda membuat dependency itu sendiri, ia diam-diam mengunci bagaimana dependency itu bekerja.

Analogi dunia nyata

Bayangkan mesin kopi di kantor. Mesin itu bergantung pada air, biji kopi, dan listrik.

• Jika mesin dirancang hanya bekerja dengan satu cartridge air proprietary yang dibelinya sendiri, Anda terikat pada pemasok itu.
• Jika mesin menerima sumber air standar apa pun, orang lain bisa memilih sumber—air keran, filter, botolan—tanpa mengubah mesin.

DI adalah pendekatan kedua itu: "mesin kopi" (kelas/fungsi Anda) fokus membuat kopi (tugasnya), sementara "persediaan" (dependency) disediakan oleh yang menyiapkannya.

Apa yang bukan DI

DI bukan keharusan memakai framework tertentu, dan bukan juga sama dengan DI container. Anda bisa melakukan DI secara manual dengan meneruskan dependency sebagai parameter (atau lewat konstruktor) dan selesai.

DI juga bukan "mocking." Mocking adalah salah satu cara untuk menggunakan DI di tes, tetapi DI sendiri hanyalah pilihan desain tentang di mana dependency dibuat.

Mengapa testabilitas dan modularitas meningkat bersamaan

Saat dependency disediakan dari luar, kode Anda menjadi lebih mudah dijalankan di konteks berbeda: produksi, unit test, demo, dan fitur masa depan.

Fleksibilitas itu membuat modul lebih bersih: bagian-bagian bisa diganti tanpa merombak seluruh sistem. Akibatnya, tes menjadi lebih cepat dan jelas (karena Anda bisa mengganti dengan pengganti sederhana), dan basis kode menjadi lebih mudah diubah (karena bagian tidak terlalu saling terkait).

Masalah Inti: Tight Coupling Membuat Perubahan Sulit

Tight coupling terjadi ketika satu bagian kode langsung memutuskan bagian lain apa yang harus digunakannya. Bentuk paling umum sederhana: memanggil new di dalam logika bisnis.

Bagaimana instansiasi langsung menciptakan coupling tersembunyi

Bayangkan fungsi checkout yang melakukan new StripeClient() dan new SmtpEmailSender() di dalamnya. Awalnya terasa nyaman—semua yang Anda butuhkan ada di situ. Tetapi itu juga mengunci alur checkout ke implementasi itu, detail konfigurasi, dan bahkan aturan pembuatannya (API key, timeout, perilaku jaringan).

Coupling itu "tersembunyi" karena tidak terlihat dari tanda tangan metode. Fungsi tampak seperti hanya memproses pesanan, tapi diam-diam bergantung pada gateway pembayaran, penyedia email, dan mungkin koneksi basis data juga.

Mengapa dependency yang sulit ditukar memperlambat perubahan

Saat dependency dikodekan secara statis, bahkan perubahan kecil memberi efek riak:

• Beralih penyedia (Stripe → Adyen) berarti mengedit logika bisnis alih-alih menukar komponen.
• Menambahkan caching, retry, atau logging memaksa Anda menyebarkan concern ke banyak titik panggilan.
• Memutakhirkan library bisa menjadi refactor besar karena pembuatan tersebar.

Tight coupling terlihat sebagai tes yang lambat atau fluktuatif

Dependency yang dikodekan keras membuat unit test melakukan pekerjaan nyata: panggilan jaringan, I/O file, jam, ID acak, atau sumber daya bersama. Tes menjadi lambat karena tidak terisolasi, dan fluktuatif karena hasil tergantung waktu, layanan eksternal, atau urutan eksekusi.

Sinyal sakit yang perlu diwaspadai

Jika Anda melihat pola ini, tight coupling kemungkinan sudah menghabiskan waktu Anda:

• State global digunakan sebagai dependency implisit
• Singleton yang sulit direset antar tes
• new berserakan di logika inti
• Kode yang tidak bisa dites tanpa database, web server, atau API key nyata

Injeksi Dependensi menanggulangi ini dengan membuat dependency eksplisit dan bisa ditukar—tanpa menulis ulang aturan bisnis setiap kali dunia berubah.

Inversi Kontrol: Memisahkan “Apa” dari “Bagaimana”

Inversi Kontrol (IoC) adalah pergeseran tanggung jawab sederhana: sebuah kelas harus fokus pada apa yang harus dilakukan, bukan bagaimana memperoleh hal yang dibutuhkannya.

Ketika sebuah kelas membuat dependency sendiri (mis. new EmailService() atau membuka koneksi basis data secara langsung), ia diam-diam mengambil dua pekerjaan: logika bisnis dan setup. Itu membuat kelas lebih sulit diubah, lebih sulit dipakai ulang, dan lebih sulit dites.

Bergantung pada abstraksi, bukan kelas konkret

Dengan IoC, kode Anda bergantung pada abstraksi—seperti interface atau tipe kontrak kecil—daripada implementasi spesifik.

Misalnya, CheckoutService tidak perlu tahu apakah pembayaran diproses lewat Stripe, PayPal, atau pemroses palsu untuk tes. Ia hanya butuh "sesuatu yang bisa menagih kartu." Jika CheckoutService menerima IPaymentProcessor, ia bisa bekerja dengan implementasi mana pun yang mengikuti kontrak itu.

Ini menjaga logika inti Anda stabil bahkan ketika alat di bawahnya berubah.

Pindahkan pembuatan keluar dari kelas

Bagian praktis dari IoC adalah memindahkan pembuatan dependency keluar dari kelas dan meneruskannya (sering lewat konstruktor). Di sinilah injeksi dependensi (DI) masuk: DI adalah cara umum untuk mencapai IoC.

Alih-alih:

• kelas memilih dan membangun kolaboratornya

Anda mendapatkan:

• kelas menerima kolaborator dari luar

Hasilnya adalah fleksibilitas: menukar perilaku menjadi keputusan konfigurasi, bukan penulisan ulang.

“Composition root”: tempat wiring terjadi

Jika kelas tidak membuat dependency mereka sendiri, sesuatu harus melakukannya. "Sesuatu" itu adalah composition root: tempat aplikasi Anda dirakit—biasanya kode startup.

Composition root adalah tempat Anda memutuskan, "Di produksi gunakan RealPaymentProcessor; di tes gunakan FakePaymentProcessor." Menjaga wiring ini di satu tempat mengurangi kejutan dan membuat sisa basis kode fokus.

Mengapa ini penting untuk tes dan refactor

IoC membuat unit test lebih sederhana karena Anda bisa menyediakan test double yang kecil dan cepat alih-alih memanggil jaringan atau database nyata.

Ia juga membuat refactor lebih aman: ketika tanggung jawab dipisah, mengubah implementasi jarang memaksa Anda mengubah kelas yang menggunakannya—selama abstraksi tetap sama.

Gaya DI Umum dan Kapan Menggunakan Masing-masing

Injeksi Dependensi (DI) bukan satu teknik—melainkan beberapa cara untuk “memberi makan” sebuah kelas hal-hal yang dibutuhkannya (seperti logger, klien DB, atau gateway pembayaran). Gaya yang Anda pilih memengaruhi kejelasan, testabilitas, dan seberapa mudah disalahgunakan.

Constructor injection (default)

Dengan constructor injection, dependency diperlukan untuk membangun objek. Kelebihan besar: Anda tidak bisa lupa menyediakannya.

Cocok ketika dependency:

• Selalu dibutuhkan agar objek bekerja
• Digunakan di beberapa metode
• Penting untuk divalidasi lebih awal (mis. null/undefined tidak boleh)

Constructor injection cenderung menghasilkan kode paling jelas dan unit test paling langsung, karena tes bisa meneruskan fake atau mock saat pembuatan.

Parameter / method injection (untuk pekerjaan sekali saja)

Kadang dependency hanya diperlukan untuk satu operasi—misalnya formatter sementara, strategi khusus, atau nilai request-scoped.

Dalam kasus itu, teruskan sebagai parameter metode. Ini menjaga objek lebih kecil dan menghindari "mengangkat" kebutuhan sekali pakai menjadi field permanen.

Property / setter injection (gunakan dengan hati-hati)

Setter injection bisa nyaman ketika Anda benar-benar tidak bisa menyediakan dependency saat konstruksi (beberapa framework atau jalur kode lama). Trade-off-nya adalah ia bisa menyembunyikan kebutuhan: kelas terlihat bisa dipakai padahal belum dikonfigurasi penuh.

Itu sering menyebabkan kejutan runtime ("kenapa ini undefined?") dan membuat tes lebih rapuh karena setup mudah terlupakan.

Aturan praktis singkat

• Jika kelas tidak bisa berfungsi tanpa itu: constructor injection.
• Jika hanya untuk satu panggilan atau perilaku varian: method/parameter injection.
• Jika perlu late wiring: setter injection, tapi tambahkan pengaman (dokumentasi jelas, validasi, atau cek fail-fast).

Bagaimana DI Meningkatkan Unit Test (Kecepatan, Isolasi, Kejelasan)

Unit test paling berguna ketika mereka cepat, terulang, dan fokus pada satu perilaku. Saat test unit bergantung pada DB nyata, panggilan jaringan, filesystem, atau jam, mereka cenderung melambat dan menjadi fluktuatif. Lebih buruk, kegagalan tidak informatif: apakah kodenya rusak atau lingkungan yang bermasalah?

DI memperbaiki ini dengan membiarkan kode menerima hal yang dibutuhkannya (akses DB, klien HTTP, penyedia waktu) dari luar. Di tes, Anda bisa menukar dependency itu dengan pengganti ringan.

Kecepatan: menjaga tes tetap in-memory

DB atau API nyata menambah waktu setup dan latensi. Dengan DI, Anda bisa menyuntikkan repository in-memory atau klien palsu yang mengembalikan respons yang telah disiapkan secara instan. Itu berarti:

• lebih banyak tes dijalankan dalam anggaran waktu yang sama
• Anda lebih mungkin menjalankannya sering
• pipeline CI tetap cepat

Isolasi: uji satu hal pada satu waktu

Tanpa DI, kode sering "new()" dependency sendiri, memaksa tes mengeksekusi seluruh stack. Dengan DI, Anda bisa menyuntikkan:

• mocks untuk memverifikasi interaksi (mis. "mengirim satu email")
• stubs untuk mengembalikan nilai tertentu (mis. "user ada")
• fakes dengan perilaku kerja sederhana (mis. store in-memory)

Tanpa hack, tanpa switch global—cukup pass implementasi berbeda.

Kejelasan: Arrange–Act–Assert yang lebih sederhana

DI membuat setup eksplisit. Alih-alih menggali konfigurasi, koneksi, atau variabel lingkungan khusus tes, Anda bisa membaca tes dan segera melihat apa yang nyata dan apa yang diganti.

Tes yang ramah DI biasanya seperti:

1. Arrange: buat service dengan repository palsu dan jam yang di-stub

2. Act: panggil metode

3. Assert: periksa nilai balik dan/atau verifikasi interaksi mock

Keterbacaan itu mengurangi kebisingan dan membuat kegagalan lebih mudah didiagnosis—persis yang Anda inginkan dari unit test.

Test Seams: Membuat Perilaku Dapat Ditukar dengan Sengaja

Sebuah test seam adalah “bukaan” yang disengaja di kode Anda di mana Anda bisa menukar satu perilaku dengan yang lain. Di produksi Anda memasang yang nyata. Di tes Anda memasang pengganti yang lebih aman dan cepat. Injeksi dependensi adalah salah satu cara termudah untuk membuat seam tanpa hack.

Di mana seam biasanya berada

Seam paling berguna di sekitar bagian sistem yang sulit dikontrol dalam tes:

• Waktu (tanggal/waktu sekarang berubah terus)
• File system (lambat, izin, cleanup)
• Email/SMS (side effect, layanan eksternal)
• Gateway pembayaran (uang nyata, kegagalan jaringan)

Jika logika bisnis memanggil bagian-bagian ini langsung, tes menjadi rapuh: gagal karena alasan yang tidak terkait dengan logika Anda (gangguan jaringan, perbedaan zona waktu, file hilang), dan sulit dijalankan dengan cepat.

Interface (atau kontrak) mengubah seam menjadi pilihan sederhana

Seam sering berbentuk interface—atau di bahasa dinamis, kontrak sederhana seperti "objek ini harus memiliki metode now()." Ide kuncinya adalah bergantung pada apa yang Anda butuhkan, bukan dari mana asalnya.

Contoh: alih-alih memanggil jam sistem langsung di service order, Anda bisa bergantung pada Clock:

• Produksi: SystemClock.now()
• Tes: FakeClock.now() mengembalikan waktu tetap

Polanya sama untuk pembacaan file (FileStore), pengiriman email (Mailer), atau penagihan kartu (PaymentGateway). Logika inti tetap sama; hanya implementasi yang dipasang berbeda.

Mengapa seams menghasilkan tes yang lebih baik

Saat Anda bisa menukar perilaku dengan sengaja:

• Tes menjadi kurang rapuh: tidak tergantung pada waktu nyata, jaringan nyata, atau state mesin bersama.
• Kasus tepi lebih mudah ditangani: Anda bisa mensimulasikan "pembayaran ditolak", "timeout penyedia email", atau "tanggal akhir bulan" tanpa setup rumit.
• Kegagalan lebih jelas: bila tes gagal, biasanya karena aturan bisnis Anda yang salah—bukan lingkungan.

Seam yang ditempatkan dengan baik mengurangi kebutuhan mocking berlebihan. Sebagai gantinya, Anda mendapatkan beberapa titik substitusi bersih yang menjaga unit test cepat, fokus, dan dapat diprediksi.

Bagaimana DI Memungkinkan Kode yang Lebih Modular

Modularitas berarti perangkat lunak Anda dibangun dari bagian-bagian independen (modul) dengan batas yang jelas: setiap modul punya tanggung jawab fokus dan cara berinteraksi yang terdefinisi.

DI mendukung ini dengan membuat batas-batas tersebut eksplisit. Alih-alih sebuah modul mencari atau membuat segala yang dibutuhkannya, ia menerima dependency dari luar. Pergeseran kecil ini mengurangi seberapa banyak satu modul "tahu" tentang modul lain.

Coupling lebih rendah secara desain

Saat kode membuat dependency sendiri (mis. new-ing client DB di dalam service), pemanggil dan dependency menjadi terikat erat. DI mendorong Anda bergantung pada interface (atau kontrak) bukan implementasi spesifik.

Itu berarti sebuah modul biasanya hanya perlu tahu:

• apa yang dibutuhkannya (mis. PaymentGateway.charge())
• bukan bagaimana diimplementasikan (Stripe vs PayPal vs sandbox)

Akibatnya, modul berubah lebih jarang bersama-sama, karena detail internal berhenti bocor ke batas.

Mengganti bagian tanpa menulis ulang pemanggil

Basis kode modular harus memungkinkan Anda menukar komponen tanpa menulis ulang pemanggil. DI membuat ini praktis:

• Ganti pengirim email nyata dengan pengirim berbasis antrian
• Pindah dari repository berbasis file ke yang berbasis database
• Tambah decorator caching di sekitar service yang ada

Dalam setiap kasus, pemanggil tetap menggunakan kontrak yang sama. Wiring berubah di satu tempat (composition root), bukan di banyak berkas.

Lebih mudah kerja paralel antar tim

Batas dependency yang jelas memudahkan tim bekerja paralel. Satu tim bisa membangun implementasi baru di balik interface yang disepakati sementara tim lain melanjutkan fitur yang bergantung pada interface itu.

DI juga mendukung refactor bertahap: Anda bisa mengekstrak modul, menyuntikkannya, dan menggantinya sedikit demi sedikit—tanpa perlu rewrite sekaligus.

Contoh Sederhana Sebelum-dan-Setelah

Melihat DI dalam kode membuatnya lebih cepat dipahami daripada definisi apa pun. Berikut contoh kecil "sebelum dan setelah" menggunakan fitur notifikasi.

Sebelum: kelas membuat dependency sendiri

Ketika sebuah kelas memanggil new secara internal, ia menentukan implementasi mana yang dipakai dan bagaimana membangunnya.

class EmailService {
  send(to, message) {
    // talks to real SMTP provider
  }
}

class WelcomeNotifier {
  notify(user) {
    const email = new EmailService();
    email.send(user.email, "Welcome!");
  }
}

Susah dites: unit test berisiko memicu perilaku email nyata (atau memerlukan stubbing global yang canggung).

test("sends welcome email", () => {
  const notifier = new WelcomeNotifier();
  notifier.notify({ email: "[email protected]" });
  // Hard to assert without patching EmailService globally
});

Setelah: suntik dependency

Sekarang WelcomeNotifier menerima objek apa pun yang cocok dengan perilaku yang dibutuhkan.

class WelcomeNotifier {
  constructor(emailService) {
    this.emailService = emailService;
  }

  notify(user) {
    this.emailService.send(user.email, "Welcome!");
  }
}

Tes menjadi kecil, cepat, dan eksplisit.

test("sends welcome email", () => {
  const fakeEmail = { send: vi.fn() };
  const notifier = new WelcomeNotifier(fakeEmail);

  notifier.notify({ email: "[email protected]" });

  expect(fakeEmail.send).toHaveBeenCalledWith("[email protected]", "Welcome!");
});

Menambah implementasi baru lebih mudah

Mau SMS nanti? Anda tidak menyentuh WelcomeNotifier. Anda cukup meneruskan implementasi berbeda:

const smsService = { send: (to, msg) => {/* SMS provider */} };
const notifier = new WelcomeNotifier(smsService);

Itulah hasil praktisnya: tes berhenti berantakan dengan detail konstruksi, dan perilaku baru ditambahkan dengan menukar dependency alih-alih menulis ulang kode lama.

DI Manual vs DI Container: Memilih Level yang Tepat

Injeksi Dependensi bisa sesederhana "meneruskan yang Anda butuhkan ke yang menggunakannya." Itu adalah manual DI. DI container adalah alat yang mengotomatisasi wiring itu. Keduanya bisa jadi pilihan bagus—triknya memilih tingkat otomatisasi yang cocok untuk aplikasi Anda.

Wiring manual: eksplisit dan mudah dipahami

Dengan manual DI, Anda membuat objek sendiri dan meneruskan dependency lewat konstruktor (atau parameter). Itu straightforward:

• Anda bisa melihat persis apa yang dibuat dan di mana.
• Tidak ada magic tersembunyi ketika sesuatu rusak.
• Cocok untuk aplikasi kecil, script, service dengan beberapa komponen, dan refactor awal.

Wiring manual juga memaksa kebiasaan desain yang baik. Jika sebuah objek butuh tujuh dependency, Anda merasakan sakitnya—seringkali itu sinyal untuk memecah tanggung jawab.

DI container: mengurangi boilerplate, manajemen lifecycle

Saat jumlah komponen tumbuh, wiring manual bisa berubah menjadi plumbing repetitif. DI container bisa membantu dengan:

• Membangun graf objek otomatis.
• Mengelola lifetime (singleton vs per-request vs transient).
• Mencentralisasi registrasi (mis. menukar service nyata dengan test double di environment tertentu).

Container bersinar pada aplikasi dengan batas yang jelas dan lifecycle—web app, service long-running, atau sistem dengan banyak fitur yang bergantung pada infrastruktur bersama.

Jangan biarkan container menyembunyikan masalah desain

Container bisa membuat desain yang terikat erat terlihat rapi karena wiring hilang. Tetapi masalah mendasar tetap ada:

• terlalu banyak dependency per kelas
• kepemilikan yang ambigu (siapa bertanggung jawab membuat/membuang resource?)
• pola "service locator" yang membuat dependency tak terlihat dan tes jadi lebih sulit

Jika menambahkan container membuat kode kurang dapat dibaca, atau pengembang berhenti tahu apa bergantung pada apa, kemungkinan Anda kebablasan.

Pendekatan seimbang yang scalable

Mulailah dengan manual DI untuk menjaga segala sesuatu jelas saat Anda membentuk modul. Tambahkan container ketika wiring menjadi repetitif atau manajemen lifecycle menjadi rumit.

Aturan praktis: gunakan manual DI di dalam kode inti/bisnis Anda, dan (opsional) container di boundary aplikasi (composition root) untuk merakit semuanya. Ini menjaga desain tetap jelas sambil mengurangi boilerplate saat proyek tumbuh.

Kesalahan Umum (dan Cara Menghindarinya)

DI bisa membuat kode lebih mudah diuji dan diubah—tapi hanya jika dipakai dengan disiplin. Berikut cara paling umum DI meleset, dan kebiasaan yang menjaga agar tetap berguna.

Over-injection ("konstruktor 12 parameter")

Jika sebuah kelas butuh daftar panjang dependency, sering kali ia melakukan terlalu banyak. Itu bukan kegagalan DI—itu DI mengungkap bau desain.

Aturan praktis: jika Anda tak bisa mendeskripsikan tugas kelas dalam satu kalimat, atau konstruktor terus bertambah, pertimbangkan memecah kelas, mengekstrak kolaborator lebih kecil, atau mengelompokkan operasi terkait di balik satu interface (hati-hati—jangan buat "god services").

Service Locator: DI yang menyembunyikan dependency nyata

Polanya biasanya terlihat seperti memanggil container.get(Foo) dari dalam kode bisnis. Rasanya praktis, tapi membuat dependency tak terlihat: Anda tak bisa tahu apa yang dibutuhkan kelas hanya dari konstruktor.

Pengujian jadi lebih sulit karena Anda harus menyiapkan state global (locator) alih-alih menyediakan sekumpulan fake lokal yang eksplisit. Lebih baik teruskan dependency secara eksplisit (constructor injection paling sederhana).

Kegagalan runtime tersembunyi: registrasi hilang dan dependensi siklik

DI container bisa gagal saat runtime ketika:

• dependency tidak ter-registrasi
• registrasi memilih implementasi yang salah untuk environment saat ini
• dua service saling bergantung (langsung atau tidak langsung), menciptakan siklus

Masalah ini menyebalkan karena muncul hanya saat wiring dijalankan.

Mitigasi praktis yang bekerja

Jaga konstruktor kecil dan fokus. Jika daftar dependency tumbuh, anggap itu perintah untuk refactor.

Tambah tes integrasi untuk wiring. Bahkan tes ringan yang membangun container aplikasi (atau wiring manual) bisa menangkap registrasi hilang dan siklus lebih awal—sebelum produksi.

Akhirnya, simpan pembuatan objek di satu tempat (sering file startup/composition root) dan jangan panggil container dari logika bisnis. Pemisahan itu menjaga manfaat utama DI: kejelasan tentang apa bergantung pada apa.

Langkah Praktis Memperkenalkan DI di Codebase yang Ada

Injeksi Dependensi paling mudah diadopsi bila Anda menganggapnya sebagai serangkaian refactor kecil dan berisiko rendah. Mulailah di tempat tes lambat atau fluktuatif, dan di area di mana perubahan sering memicu ripple effect.

Daftar cepat: di mana DI memberi keuntungan pertama

Cari dependency yang membuat kode sulit dites atau sulit dipahami:

• I/O: akses file, panggilan basis data, permintaan jaringan
• Waktu: "now", zona waktu, delay, scheduler
• Randomness: UUID, angka acak, pengacakan
• API/SDK eksternal: penyedia pembayaran, layanan email, analytics, feature flags

Jika fungsi tidak bisa dijalankan tanpa menjangkau luar proses, biasanya kandidat yang baik.

Langkah refactor bertahap (pola yang bisa diulang)

1. Pilih satu seam: tentukan satu dependency eksternal yang sekarang di-new atau dipanggil langsung.
2. Ekstrak interface (atau kontrak sederhana): definisikan perilaku yang Anda butuhkan (sering 1–3 metode). Buat kecil.
3. Buat implementasi nyata: bungkus dependency konkret saat ini di balik interface itu.
4. Suntikkan: teruskan interface lewat konstruktor atau argumen fungsi. Pilih opsi termudah yang cocok.
5. Update wiring produksi: buat implementasi nyata di satu tempat (entry point, factory, composition root) dan teruskan ke pemakai.
6. Update tes: ganti implementasi nyata dengan fake/mock/stub yang memberi respons prediktabel.

Pendekatan ini membuat setiap perubahan bisa direview dan memungkinkan Anda berhenti setelah langkah apa pun tanpa merusak sistem.

Menjaga kohesi modul saat menyuntik dependency

DI bisa tanpa sengaja mengubah kode menjadi "semua bergantung pada semuanya" jika Anda menyuntik terlalu banyak.

Aturan baik: suntikkan kapabilitas, bukan detail. Misalnya, suntikkan Clock alih-alih "SystemTime + TimeZoneResolver + NtpClient". Jika sebuah kelas butuh lima layanan tidak terkait, mungkin ia melakukan terlalu banyak—pertimbangkan pemisahan.

Juga, hindari meneruskan dependency melalui banyak lapisan "sekedar berjaga-jaga". Suntikkan hanya di tempat digunakan; pusatkan wiring di satu tempat.

Catatan tentang DI saat Anda menghasilkan atau menscaffold aplikasi

Jika Anda memakai code generator atau workflow cepat untuk membuat fitur, DI jadi makin berharga karena menjaga struktur saat proyek tumbuh. Contohnya, ketika tim menggunakan Koder.ai untuk membuat frontend React, service Go, dan backend PostgreSQL dari spesifikasi berbasis chat, menjaga composition root yang jelas dan interface yang ramah DI membantu agar kode yang dihasilkan tetap mudah dites, direfaktor, dan mampu menukar integrasi (email, pembayaran, penyimpanan) tanpa menulis ulang logika inti.

Aturannya tetap sama: simpan pembuatan objek dan wiring environment-spesifik di boundary, dan biarkan kode bisnis fokus pada perilaku.

Apa yang diukur setelah perubahan

Anda harus bisa menunjuk perbaikan konkret:

• Tes unit lebih cepat (kurang menunggu DB/jaringan/waktu)
• Tes lebih terisolasi (lebih sedikit setup global dan state bersama)
• Batas lebih bersih (kontrak jelas antar modul)
• Perubahan lebih mudah (menukar klien API atau strategi penyimpanan dengan edit minimal)

Jika ingin langkah berikutnya, dokumentasikan "composition root" Anda dan jaga agar tetap membosankan: satu file yang merakit dependency, sementara sisa kode tetap fokus pada perilaku.