Ada banyak proyek jenis Injector Sederhana untuk berbagai bahasa pemrograman yang memungkinkan, dengan nama kelas, antarmuka atau namespace, dan terkadang folder, untuk mendaftarkan kelas atau seluruh kelompok kelas yang disatukan oleh fitur ini dalam beberapa kasus. Ini dilakukan untuk tujuan membuat instance objek secara otomatis tanpa secara eksplisit menentukan dependensinya. Ini pendaftaran sekelompok objek dengan fitur umum di register untuk tujuan instansiasi lebih lanjut, saya sebut pendaftaran dependensi otomatis.
Jika Anda secara eksplisit membuat instance kelas saat mendaftarkannya di register ketergantungan, maka ini bukan topik artikel ini.
Dan apa yang salah dengan itu?
Dalam posting ini saya akan berbicara tentang frustrasi saya dengan proyek-proyek yang menggunakan registrasi ketergantungan otomatis. Ayo pergi secara berurutan.
Waktu proses vs waktu kompilasi
Dengan menggunakan alat pendaftaran ketergantungan otomatis, kami memindahkan pemeriksaan kelengkapan dependensi terdaftar ke runtime. Artinya, jika pada saat meluncurkan program kami tidak memiliki implementasi antarmuka yang diperlukan untuk menjalankan kode, kami akan mempelajarinya paling baik pada awal aplikasi, dan paling buruk - selama pengoperasian sistem dan dari pengguna.
Berikut contohnya. Jika dalam proyek pendaftaran beberapa kelas terjadi, katakanlah, oleh namespace mereka, dan Anda pada suatu saat memindahkan kelas darinya, maka Anda akan mempelajari masalah tersebut pada waktu proses. Hal yang sama akan terjadi dengan pendaftaran otomatis melalui antarmuka, dengan satu-satunya perbedaan bahwa pemindahan tidak akan menjadi masalah, tetapi menghapus antarmuka akan menyebabkan masalah, yang akan Anda pelajari setelah memulai aplikasi.
Refactoring jauh lebih rumit
Tidak hanya refactoring, tetapi juga mempelajari kode menjadi sangat sulit. Ini karena ketika menggunakan registrasi ketergantungan otomatis, akses ke kapabilitas modern dari lingkungan pengembangan hilang, yang akan memungkinkan kita untuk mengetahui siapa yang menggunakan kelas ini dalam satu klik (temukan referensi) dan menjawab pertanyaan berikut:
- Bisakah saya menghapus kelas ini?
- Dapatkah saya memindahkan kelas ini ke namespace / folder lain?
dll.
Selain fakta bahwa kami kehilangan kesempatan untuk memeriksa kelengkapan dependensi yang diperlukan selama kompilasi, refactoring apa pun adalah harapan kami memiliki mekanisme runtime dalam bentuk pengujian, verifikasi pohon dependensi, dan sejenisnya. Dan harapannya adalah itu berhasil. Perlu dicatat bahwa mekanisme ini tidak hanya tidak menjamin 100% bahwa komposisi kode sudah benar, tetapi juga jauh lebih lambat daripada kompilasi.
Menyembunyikan kompleksitas sebenarnya dari sistem
Saat membuat instance kelas secara manual dan semua dependensinya, Anda mungkin agak takut dengan monstrositas file tempat semua tindakan ini akan berlangsung. Melihat ribuan baris kode untuk membuat instance kelas dan membandingkannya dengan selusin saat menggunakan pendaftaran ketergantungan otomatis, saya benar-benar ingin menyerah pada godaan dan pergi ke "sisi gelap".
Tapi apa yang dikatakan ribuan baris kode ini untuk membuat contoh objek kepada kita? Fakta bahwa modul ini kompleks, besar dan kita harus memikirkan tentang penyusunannya melalui alokasi submodul (yang secara eksplisit menunjukkan dependensinya), atau membagi modul ini menjadi beberapa.
Ini mungkin tampak abstrak, tetapi menghilangkan momen-momen canggung seperti memberi contoh ratusan objek dari mata kita mengarah pada fakta bahwa ukuran proyek tumbuh tak terkendali, dan akibatnya, kita kehilangan momen ketika itu harus dibagi menjadi beberapa proyek.
Dependensi ekstra
Dengan mendaftarkan dependensi dan tidak mengontrol penggunaannya, cepat atau lambat kita sampai pada situasi di mana, ketika aplikasi dimulai, secara signifikan lebih banyak kelas yang terdaftar daripada yang sebenarnya dibutuhkan. Penambahan sederhana ke folder atau implementasi antarmuka dapat mengakibatkan kelas ini didaftarkan dalam kasus umum.
Ringkasan
Apakah mungkin untuk hidup dengan semua kekurangan ini dan tidak menyadarinya? Tentu! Tapi saya yakin itu mengembangkan kebiasaan pembangunan yang salah. Intinya adalah kompilasi dan pengetikan kode adalah alat untuk memeriksa kebenaran sistem. Menolak mereka, kami menemukan fakta bahwa sistem menjadi rapuh, sehingga pengembang takut untuk mengubah apa pun di dalamnya. Dan ketakutan pengembang untuk mengubah kode sudah mengarah pada fakta bahwa kualitas basis kode menurun, setelah itu menjadi proses yang mahal untuk membuat perubahan pada kode tersebut.
Apa yang bagus tentang pendaftaran ketergantungan otomatis?
Dan sungguh, apa yang bagus? Saya sarankan untuk membahas di komentar mengapa metode ini mendapatkan popularitas. Tentunya dia memiliki penggemar di antara para pembacanya.