Соображения для разработки хорошо спроектированных зависимостей

Question

Я начинаю задумываться о реализации контейнеров Inversion of Control в своих будущих проектах или рефакторингах, и мне было интересно, какие принципы (помимо шаблонов GoF) было бы интересно иметь в виду, когда речь идет о правильном проектировании зависимостей. Скажем, мне нужно спроектировать простое консольное приложение, которое будет искать книгу (по ISBN) в Amazon, если оно сможет получить доступ к Интернету или откатится к локальной базе данных (SQLite, SqlServerCE), когда нет доступного соединения. Таким образом, первоначальный дизайн может быть в значительной степени:

• IAmazonSearchProvider
• ILocalSearchProvider
• IResultsGenerator (в зависимости от IAmazonSearchProvider или ILocalSearchProvider)
• IOutputFormatter
• ConsoleApplication (зависит от IOutputFormatter)

Любое руководство будет по-настоящему оценено, большое спасибо заранее.

Answer 1

Это довольно нормальный подход, и он неплохой, но он сильно фокусируется на механике и может повлечь за собой риск нарушения Принципа повторного использования абстракций . На высоком уровне было бы лучше, если бы вы могли заставить API описывать что он делает вместо как это делает. Следование Голливудскому принципу является важным началом.

При проектировании абстракций предпочитает композицию наследованию . Помимо этого, отдавайте предпочтение Ролевые интерфейсы над Интерфейсы заголовков .

В настоящее время я работаю с свободным рейтингом методов ролевого интерфейса следующим образом (где Команды лучше всего ):

1. Команда
2. Закрытие операций
3. Сокращение ввода
4. Типы возвращаемых данных

Answer 2

Я предполагаю, I* - это интерфейсы.IResultsGenerator и ILocalSearchProvider звучат как реализации (а не интерфейсы) IResultsGenerator.Кроме того, что-то должно зависеть от IResultsGenerator, я рекомендую это ConsoleApplication.

Остальное выглядит отлично.