Какой эффект оказывает Принцип инверсии зависимостей на структуру проекта?
В случае, если я хочу использовать DIP для разработки гипотетического модульного проекта C ++. Из-за модульности я решил полностью реализовать одну особенность в одной библиотеке A, Другая библиотека B (или два, или три …) использует эту функцию (например, механизм регистрации):
class ILogger
{
virtual void log(const std::string& s) = 0;
};
Где я должен поместить этот интерфейс физически? Некоторые блогеры, кажется, предполагают, что, поскольку интерфейс принадлежит его пользователям (из-за DIP) вы должны поставить интерфейс на стороне пользователя (или же Вот). Это также улучшило бы тестируемость, потому что вам не нужно, чтобы какая-либо реализация была связана с тестом.
Это будет означать, что сама библиотека A не будет компилироваться, потому что ей не хватает интерфейса. Это также будет означать, что если библиотека C будет также использование средство регистрации это также принесет интерфейс ILogger, который сломает ODR?! Эту проблему можно решить, введя дополнительную библиотеку D уровня пакета, которая содержит только интерфейс. Но главная проблема остается:
Где поставить интерфейс? Я читаю оригинал бумага о DIP, но я не могу согласиться с интерпретацией, что я не должен помещать интерфейсы в библиотеку. У меня есть ощущение, что эта статья предназначена для руководства как думать о разработке (как «пользователи определяют интерфейс, а не разработчики»). Это правильно? Как вы используете принцип инверсии зависимости?
Решение
Программное обеспечение можно рассматривать как комбинацию разных слоев:
-
Один уровень — уровень реализации (грубо говоря, уровень функции)
-
Еще один способ взаимодействия структур данных (уровень класса, в котором в первую очередь должен применяться DIP)
-
И еще один способ взаимодействия компонентов (уровень пакета). Мы также хотели бы применить некоторый DIP здесь, если это возможно. Роберт К. Мартин настаивает на том факте, что этот уровень в основном зависит от бизнеса (что бы это ни значило), поэтому принципы немного отличаются: принцип стабильных зависимостей и принцип стабильных абстракций (см. Образец и практику принципа Мартина)
Теперь следует также подчеркнуть, что принципы разработки программного обеспечения следует применять только в том случае, если вам необходимо решить проблему, которую они решают. Пока у вас нет проблем, не используйте их.
На уровне класса вы должны использовать DIP, если у вас есть веские основания полагать, что ваш механизм ведения журнала будет реализован несколькими классами. Если вы считаете, что в настоящее время будет только один механизм лесозаготовок, то это прекрасно не использовать DIP, потому что нет проблем для решения.
Теперь такой же выбор должен быть сделан на уровне пакета. Однако руководство по выбору упаковки — это развертывание. Вот:
class ILogger {
virtual void log(const std::string& s) = 0;
};
class A : public ILogger {
…
};
class A2 : public ILogger {
…
};
- Если вы считаете (по деловым причинам), что имеет смысл выпустить A без A2, то создайте 4 библиотеки: одну для ILogger, одну для пользовательского класса B, одну для A, одну для A2.
- Если по каким-либо причинам A и A2 be должны быть выпущены вместе, то создайте только одну библиотеку для ILogger, A и A2. Если позже они должны быть выпущены отдельно, то сломайте вашу библиотеку, но не сейчас, потому что помните: YAGNI.
- Если у вас есть только одна зависимость от ILogger, то также может иметь смысл создать только одну библиотеку со всем.
- Не выпускайте библиотеку с ILogger и B, а другую с A, потому что тогда у вас нет никаких преимуществ по сравнению с решением 3, это более сложный и, кроме того, может нарушить другой принцип для пакетов: принцип ациклических зависимостей.
Во всяком случае, это решение в основном зависит от бизнеса. Также помните, что упаковка должна выполняться снизу вверх: создавайте новую упаковку только тогда, когда у вас есть много классов, которые вы хотите организовать. Пока у вас не так много уроков, не пытайтесь принимать ранние решения, потому что вы почти наверняка ошибетесь.
Другие решения