По-перше, створення споріднених об'єктів класів дійсно може здійснюватися новими об'єктами. Однак, коли проєкт занадто великий і об'єкт має забагато залежностей, потрібно писати багато нового коду при створенні об'єкта, і може бути метод прямого виклику об'єкта після забуття інстанції деяких залежних об'єктів, тоді з'явиться виняток нульового вказівника. Якщо цей процес залишити на управління контейнером, нам не доведеться турбуватися про створення об'єктів, і при використанні залежних об'єктів не буде жодних винятків null pointer, а код можна спростити. По-друге, атрибути, які використовуються в процесі виклику методу, можуть бути атрибутами екземпляра, якщо всі вони визначені як статичні, то що щодо даних, що використовуються в методі? Якщо ви визначаєте всі методи як статичні, то властивості класу, на який посилається метод, також мають бути визначені як статичні, що еквівалентно глобальним атрибутам, тому обов'язково виникнуть проблеми синхронізації даних. Насправді логічно замислитися над принципами програмування, викладеними в шаблоні проєктування, які всі спрямовані на створення високочитабельного, легкого в підтримці та масштабованого коду. З найкращими побажаннями!
Зручно збирати програмне забезпечення у вигляді будівельних блоків, а також створювати програмне забезпечення з високою когезією та низькою взаємодією (вилучення залежностей із коду) Спільна розробка, налагодження коду (не потрібно інтегрувати компоненти разом, їх можна протестувати окремо), і створений код є більш надійним.
Розробка проєкту приділяє увагу високому когезійному та низькому зв'язку, а використання ін'єкції залежностей дозволяє уникнути використання нової області ключових слів для створення об'єктів, зменшуючи таким чином зв'язок між класами
|