Необходимость интерфейсов, инъекций в уникальный проект

Question

Почему я должен реализовывать интерфейсы и внедрение зависимостей на сайте, почти не имея шансов на повторное использование или обновление кем-либо еще?

Answer 1

Когда вы узнали, как программировать компьютер, вы развили своего рода «мышечную память» своего ремесла. На протяжении многих лет вы продолжаете программировать в том же духе. Большинство людей не изучают все изящные принципы ООП с самого начала, поэтому им кажется, что им нужно больше усилий, чем тому, чему они научились.

Вы должны привыкнуть использовать методы проектирования ООП всякий раз, когда вы используете язык ООП, потому что это сделает вас лучшим разработчиком в целом. Ваша цель должна состоять в том, чтобы переучить мышечную память от программирования, чтобы использовать эти методы. Тогда вам не придется задавать эти вопросы и предполагать, что методы каким-то образом «мешают» вашему программированию. Вы становитесь программистом, который так программирует.

Answer 2

Это часто делает модульное тестирование немного проще. Например, у вас может быть тип, который использует другой тип, который подключается к базе данных. Для модульного тестирования первого типа вы можете ввести тестовый макет вместо второго типа, что позволит вам эффективно выполнить модульное тестирование первого типа без косвенного подключения к базе данных через второй тип.

Answer 3

Почему, действительно?

Я не думаю, что интерфейсы и внедрение - это только повторное использование или обновление.

Лично я использую интерфейсы и DI для всех проектов. Недостаточно накладных расходов, чтобы избежать их выгоды.

Answer 4

Потому что предположение, которое вы делаете, является тем же предположением, которое привело к 2000 году.

Answer 5

Я нахожу, что это намного упрощает повторное использование моего кода способами, о которых я еще не думал. Это также упрощает изменение работы кода без изменения исходного кода.

Я использую Spring.NET для внедрения зависимостей.

Допустим, у вас есть класс Machine, у которого есть функция DoWork (). Затем вы создаете интерфейс IWorkAlgorithm с конкретными реализациями алгоритма для каждой машины.

Каждый экземпляр Machine имеет встроенный IWorkAlgorithm, и Machine.DoWork () вызывает внедренную реализацию.

Теперь у вас есть следующие преимущества:

<Ол>

Вы можете заменить новые реализации, просто отредактировав файл XML.

Вы можете изменить свойства каждой реализации (тайм-ауты, ограничения и т. д.), отредактировав файл XML.

Вы можете повторно использовать свои реализации вне класса Machine.

Answer 6

Если вы занимаетесь объектно-ориентированным программированием, даже если вы единственный разработчик, который будет смотреть на код, вы все равно должны пройти модульное тестирование, и это усложняется, если вы не используете внедрение зависимостей.

Не забывайте, что " другой разработчик " на вашем программном обеспечении вполне может быть вы. Вы можете взломать массу сильно взаимосвязанного, взаимозависимого кода, который работает, и даже понять его во время работы над ним, но как только вы отойдете от проекта, даже на пару дней, вы начнете забыть обо всех мелочах, которые препятствовали распутыванию клубка пряжи.

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