Pertama, pembuatan objek kelas terkait memang dapat dilakukan oleh yang baru. Namun, ketika proyek terlalu besar dan objek memiliki terlalu banyak dependensi, kita perlu menulis banyak kode baru saat membangun objek, dan mungkin ada metode untuk memanggil objek secara langsung setelah lupa membuat instance beberapa objek dependen, maka akan ada pengecualian penunjuk null. Jika proses ini diserahkan kepada manajemen kontainer, kita tidak perlu khawatir tentang instansiasi objek, dan tidak akan ada pengecualian penunjuk null saat menggunakan objek dependen kapan saja, dan kode dapat disederhanakan.
Kedua, atribut yang digunakan dalam proses pemanggilan metode dapat berupa atribut instans, jika semuanya didefinisikan sebagai statis, bagaimana dengan data yang digunakan dalam metode tersebut? Jika Anda mendefinisikan semua metode sebagai statis, maka properti kelas yang direferensikan dalam metode juga harus didefinisikan sebagai statis, yang setara dengan atribut global, sehingga pasti akan ada masalah sinkronisasi data.
Faktanya, masuk akal untuk memikirkan prinsip-prinsip pemrograman yang diberikan dalam pola desain, semuanya ditujukan untuk membangun kode yang sangat mudah dibaca, mudah dipelihara, dan dapat diskalakan. Harapan terbaik!
Lebih mudah untuk merakit perangkat lunak dengan cara blok bangunan, dan lebih mudah untuk membuat perangkat lunak dengan kohesi tinggi dan kopling rendah (mengekstrak dependensi dari kode)
Pengembangan kolaboratif, debugging kode (tidak perlu mengintegrasikan komponen bersama-sama, mereka dapat diuji secara terpisah), dan kode yang dibuat lebih kuat.
Pengembangan proyek memperhatikan kohesi tinggi dan kopling rendah, dan penggunaan injeksi dependensi dapat menghindari penggunaan area kata kunci baru untuk membuat objek, sehingga mengurangi kopling antar kelas
|
Diposting pada 10/02/2019 18.14.29
|
|
|
