“Инверсия Зависимости” и “Дизайн к Интерфейсам” те же принципы?
Исходный файл, который вы показали, содержит только определение main(). Другие вспомогательные функции, такие как getChoice() и т. Д., Только что объявлены, а определение отсутствует в текущем файле. Если определения для этих вспомогательных функций находятся в других файлах, их также следует скомпилировать.
Если предположить, что main() включено в main.c, а вспомогательные функции находятся в helper.c, то команда для их компиляции в gcc будет
gcc main.c helper.c -o executive_name
. Лучший способ справиться с этим поместить все прототипы функций (или объявления) в файл заголовка, скажем, helper.h, и включить вспомогательный файл как в main.c, так и в helper.c
2 ответа
"дизайн контракта" и "внедрение зависимости" очень тесно связаны, но имеют разные уровни абстракции. "дизайн контракта" является очень общим принципом разработки, который может поддерживаться различными методами; На языке, который имеет подобную Java систему классов, Вы, одна техника состоит в том, чтобы использовать интерфейсы для предотвращения зависимостей от реального класса. "внедрение зависимости" является другой техникой, которая часто полагается на существование интерфейсов для функционирования (но не должен всегда делать этого - Это зависит от языка). Я сказал бы, что "внедрение зависимости" поддерживает принцип "дизайна контракта".
Дизайн к интерфейсам (как вариант дизайна контракта) поддерживает инверсию зависимости. Оба уменьшают связь. Однако:
- Дизайн к интерфейсам и DBC ничего не говорит о том, как объекты создаются (например, DIP, абстрактные фабрики, методы фабрики).
- Инверсия зависимости (внедрение зависимости) обычно полагается на интерфейсы, но фокусируется на объектном жизненном цикле, а не дизайне класса. Можно использовать DIP с абстрактными базовыми классами, при необходимости таким образом, Вы не посвящаете себя действительно чистым интерфейсам.
Подходы имеют тенденцию дополнять друг друга.