Pelajari bagaimana injeksi dependensi membuat kode lebih mudah dites, direfaktor, dan diperluas. Jelajahi pola praktis, contoh, dan jebakan umum yang harus dihindari.
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.
Bayangkan mesin kopi di kantor. Mesin itu bergantung pada air, biji kopi, dan listrik.
DI adalah pendekatan kedua itu: "mesin kopi" (kelas/fungsi Anda) fokus membuat kopi (tugasnya), sementara "persediaan" (dependency) disediakan oleh yang menyiapkannya.
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.
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).
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.
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.
Saat dependency dikodekan secara statis, bahkan perubahan kecil memberi efek riak:
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.
Jika Anda melihat pola ini, tight coupling kemungkinan sudah menghabiskan waktu Anda:
new berserakan di logika intiInjeksi Dependensi menanggulangi ini dengan membuat dependency eksplisit dan bisa ditukar—tanpa menulis ulang aturan bisnis setiap kali dunia berubah.
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.
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.
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:
Anda mendapatkan:
Hasilnya adalah fleksibilitas: menukar perilaku menjadi keputusan konfigurasi, bukan penulisan ulang.
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.
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.
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.
Dengan constructor injection, dependency diperlukan untuk membangun objek. Kelebihan besar: Anda tidak bisa lupa menyediakannya.
Cocok ketika dependency:
Constructor injection cenderung menghasilkan kode paling jelas dan unit test paling langsung, karena tes bisa meneruskan fake atau mock saat pembuatan.
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.
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.
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.
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:
Tanpa DI, kode sering "new()" dependency sendiri, memaksa tes mengeksekusi seluruh stack. Dengan DI, Anda bisa menyuntikkan:
Tanpa hack, tanpa switch global—cukup pass implementasi berbeda.
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:
Arrange: buat service dengan repository palsu dan jam yang di-stub
Act: panggil metode
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.
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.
Seam paling berguna di sekitar bagian sistem yang sulit dikontrol dalam tes:
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.
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:
SystemClock.now()FakeClock.now() mengembalikan waktu tetapPolanya sama untuk pembacaan file (FileStore), pengiriman email (Mailer), atau penagihan kartu (PaymentGateway). Logika inti tetap sama; hanya implementasi yang dipasang berbeda.
Saat Anda bisa menukar perilaku dengan sengaja:
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.
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.
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:
PaymentGateway.charge())Akibatnya, modul berubah lebih jarang bersama-sama, karena detail internal berhenti bocor ke batas.
Basis kode modular harus memungkinkan Anda menukar komponen tanpa menulis ulang pemanggil. DI membuat ini praktis:
Dalam setiap kasus, pemanggil tetap menggunakan kontrak yang sama. Wiring berubah di satu tempat (composition root), bukan di banyak berkas.
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.
Melihat DI dalam kode membuatnya lebih cepat dipahami daripada definisi apa pun. Berikut contoh kecil "sebelum dan setelah" menggunakan fitur notifikasi.
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
});
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!");
});
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.
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.
Dengan manual DI, Anda membuat objek sendiri dan meneruskan dependency lewat konstruktor (atau parameter). Itu straightforward:
Wiring manual juga memaksa kebiasaan desain yang baik. Jika sebuah objek butuh tujuh dependency, Anda merasakan sakitnya—seringkali itu sinyal untuk memecah tanggung jawab.
Saat jumlah komponen tumbuh, wiring manual bisa berubah menjadi plumbing repetitif. DI container bisa membantu dengan:
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.
Container bisa membuat desain yang terikat erat terlihat rapi karena wiring hilang. Tetapi masalah mendasar tetap ada:
Jika menambahkan container membuat kode kurang dapat dibaca, atau pengembang berhenti tahu apa bergantung pada apa, kemungkinan Anda kebablasan.
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.
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.
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").
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).
DI container bisa gagal saat runtime ketika:
Masalah ini menyebalkan karena muncul hanya saat wiring dijalankan.
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.
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.
Cari dependency yang membuat kode sulit dites atau sulit dipahami:
Jika fungsi tidak bisa dijalankan tanpa menjangkau luar proses, biasanya kandidat yang baik.
new atau dipanggil langsung.Pendekatan ini membuat setiap perubahan bisa direview dan memungkinkan Anda berhenti setelah langkah apa pun tanpa merusak sistem.
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.
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.
Anda harus bisa menunjuk perbaikan konkret:
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.
Injeksi Dependensi (DI) berarti kode Anda menerima hal-hal yang dibutuhkannya (basis data, logger, jam, klien pembayaran) dari luar alih-alih membuatnya sendiri.
Secara praktis, itu biasanya terlihat seperti meneruskan dependency ke konstruktor atau parameter fungsi sehingga menjadi eksplisit dan dapat ditukar.
Inversi Kontrol (IoC) adalah gagasan yang lebih luas: sebuah kelas harus fokus pada apa yang dilakukannya, bukan bagaimana mendapat kolaboratornya.
DI adalah teknik umum untuk mencapai IoC dengan memindahkan pembuatan dependency ke luar dan meneruskannya masuk.
Jika sebuah dependency dibuat dengan new di dalam logika bisnis, dependency itu menjadi sulit untuk diganti.
Itu menyebabkan:
DI membantu tes tetap cepat dan deterministik karena Anda bisa menyuntikkan test double alih-alih menggunakan sistem eksternal nyata.
Pertukaran umum:
Container DI bersifat opsional. Mulailah dengan manual DI (teruskan dependency secara eksplisit) ketika:
Pertimbangkan container saat wiring menjadi repetitif atau Anda membutuhkan manajemen lifecycle (singleton/per-request).
Gunakan constructor injection ketika dependency diperlukan agar objek berfungsi dan dipakai di banyak metode.
Gunakan method/parameter injection ketika hanya dibutuhkan untuk satu panggilan (mis. nilai request-scoped, strategi sekali pakai).
Hindari setter/property injection kecuali benar-benar perlu late wiring; tambahkan validasi untuk gagal cepat jika hilang.
Composition root adalah tempat Anda merakit aplikasi: membuat implementasi dan meneruskannya ke service yang membutuhkannya.
Letakkan dekat startup aplikasi (entry point) sehingga sisa kode tetap fokus pada perilaku, bukan wiring.
Test seam adalah titik yang sengaja dibuat agar perilaku bisa ditukar.
Tempat yang baik untuk seam adalah concern yang susah dites:
Clock.now())DI membuat seam dengan membiarkan Anda menyuntikkan implementasi pengganti dalam tes.
Kesalahan umum meliputi:
container.get() di dalam kode bisnis menyembunyikan dependency nyata; lebih baik teruskan parameter secara eksplisit.Gunakan refaktor kecil dan berulang:
Ulangi untuk seam berikutnya; berhenti kapan saja tanpa perlu rewrite besar.