Во-первых, создание связанных объектов классов действительно может осуществляться новыми. Однако, когда проект слишком велик и объект имеет слишком много зависимостей, нам нужно писать много нового кода при построении объекта, и может появиться метод прямого вызова объекта после забыта инстанцировать некоторые зависимые объекты, тогда появится исключение null указателя. Если этот процесс оставить на управление контейнером, нам не нужно беспокоиться о создании объектов, и при использовании зависимых объектов не будет исключений нулевых указателей, а код можно упростить.
Во-вторых, атрибуты, используемые в процессе вызова метода, могут быть атрибутами экземпляра, если все они определены как статические, что насчёт данных, используемых в методе? Если вы определите все методы как статические, то свойства класса, на который ссылается метод, также должны быть определены как статичные, что эквивалентно глобальным атрибутам, поэтому обязательно возникнут проблемы синхронизации данных.
На самом деле, логично задуматься о принципах программирования, изложенных в шаблоне проектирования, направленных на создание высокочитаемого, простого в обслуживании и масштабируемого кода. С наилучшими пожеланиями!
Удобно собирать программное обеспечение в виде строительных блоков, а также создавать программное обеспечение с высокой когезией и низкой связностью (извлекая зависимости из кода)
Совместная разработка, отладка кода (не нужно интегрировать компоненты, их можно протестировать отдельно), и созданный код более надёжный.
Разработка проекта уделяет внимание высокой когезии и низкой связности, а использование инъекции зависимостей позволяет избежать использования новой области ключевых слов для создания объектов, тем самым снижая связь между классами
|
Опубликовано 10.02.2019 18:14:29
|
|
|
