Статический метод или DI

Question

Я новичок в Java или в программировании в целом, и обычно у меня есть экземпляр класса Main в качестве статического метода для легкого доступа к нему из других классов. Например. private static Main instance; тогда я бы сделал для него геттер public static Main getInstance(), а для других классов я бы просто сделал Main.getInstance().otherMethods();, чтобы получить другие методы и переменные, которые были объявлены в классе Main.

Мне недавно сказали, что это не рекомендуется, и мне сказали, что я должен вместо этого использовать Dependency Injection. У меня вопрос, почему я не должен использовать это в Java и почему Dependency Injection будет лучше? В чем разница между использованием этого способа или просто передачей его в качестве параметра метода и каковы его преимущества и недостатки?

Answer 1

Во-первых, внедрение зависимостей не зависит от java. Это заблуждение. Это хорошая идея на многих других языках. Отделение связующего кода от бизнес-логики (а именно, что такое внедрение зависимостей) - хорошая идея, независимо от того, что вы используете, и конкретный случай разделения интересов. Это никогда не плохая идея. Вы должны делать это на каждом языке, который вы используете. Как вы делаете это работает по-разному для разных языков.

Второе: Внедрение зависимостей своими руками легко : это шаблон проектирования, а не рамки. Хотя, конечно, для этого есть несколько хороших Java-фреймворков, которые вы, вероятно, захотите использовать. Написание кода клея вручную - работа обезьян. Автоматизация это хорошая идея.

То, как это работает, просто применяет несколько правил:

1. Модули / классы / объекты / функции кода и т. Д., Содержащие бизнес-логику, сами по себе не создают ничего, что им нужно (иначе говоря, зависимости). Вместо этого все, что им нужно, дается им через параметры (иначе как инъекция). В Java лучшее место для этого - конструктор. Внедрение в сеттер - это тоже вещь, но инжектор в конструктор - это то, что вы должны делать.
2. Код, который строит / конструирует / инициализирует / конфигурирует как конструкторы, основные методы, методы beforeTest и т. Д., Не должен выполнять работу, кроме этой: не помещайте здесь бизнес-логику. Это где клей код идет. Клеевой код никогда не должен смешиваться с бизнес-логикой.

Вот и все. Просто. Создавайте вещи, вводите их там, где это необходимо. Делайте это последовательно. Если вы обнаружите, что вам нужно ввести много материала в одном месте, это проблема сцепления и сплоченности: исправьте ее, потому что ваш дизайн сломан.

Здесь нет ничего специфичного для Java. Это логическое следствие применения принципов SOLID. Вы не можете сделать это и НЕ делать инъекцию зависимостей. Вы можете сделать это в Javascript, Ruby, Python, Haskell, lisp и т. Д. Каждый раз, когда вы слышите о том, что код сложно тестировать или поддерживать, вы обнаружите, что люди смешивали связующий код и логику и создавали большой беспорядок. У каждого из этих языков есть хорошие идиомы для этого.

Answer 2

Уже есть тонны вопросов и ответов по этому поводу.Вы можете искать «почему DI», чтобы получить много теории о причинах.Например: Почему используется внедрение зависимостей?

Ключевые преимущества DI:

• Гибкость - есливам когда-нибудь нужно заменить компонент или использовать несколько компонентов вместо одного, тогда DI позволяет вам корректировать ваш код только с несколькими изменениями.

• Проще для единиц-test - вы можете внедрить mock-реализацию зависимого компонента в тестируемый компонент и протестировать только целевой компонент.

Пример из реальной жизни:

Я однажды видел проект, который использовал класс доступа к базе данных Singleton.Во всем приложении была единственная глобальная константа:

public static final DB_INSTANCE = ...;

, которая использовалась по всему приложению, например:

DB_INSTANCE.runQuery("SELECT ...");

Затем запрос на функционирование стал работатьс несколькими базами данных одновременно (разновидность "шардинга").Синглтон DB_INSTANCE представлял собой единую базу данных, поэтому для этой функции требовалось переписать тонн строк кода - теперь компонентам вводится "экземпляр db".