Лучше иметь много интерфейсов или только один?

Question

Я работал над этой системой плагинов. Я думал, что прошел дизайн и начал реализацию. Теперь мне интересно, стоит ли мне пересмотреть мой дизайн. Моя проблема заключается в следующем:

В настоящее время в моем дизайне есть:

1. Интерфейсный класс FileNameLoader для загрузки имен всех общих библиотек, которые необходимо загрузить моему приложению. загрузить все файлы в каталоге, загрузить все файлы, указанные в XML-файле, загрузить все файлы, введенные пользователем и т. д.

2. Класс интерфейса LibLoader, который фактически загружает общий объект. Этот класс отвечает за загрузку общего объекта только после того, как ему присвоено имя файла. Существует несколько способов загрузки разделяемой библиотеки. то есть используйте RTLD_NOW / RTLD_LAZY ...., проверьте, загружен ли lib и т. д.

3. ABC Plugin, который загружает нужные мне функции из дескриптора в библиотеку после того, как этот дескриптор предоставлен. Есть так много способов, которыми это может измениться.

4. Класс интерфейса PluginFactory, который создает Plugin с.

5. Азбука PluginLoader, которая является материнским классом, который управляет всем.

Теперь моя проблема в том, что я чувствую, что FileNameLoader и LibLoader могут войти внутрь Plugin. Но это будет означать, что если кто-то хочет просто изменить RTLD_NOW на RTLD_LAZY, ему придется изменить Plugin класс. С другой стороны, я чувствую, что здесь слишком много уроков. Пожалуйста, дайте некоторую информацию. Я могу опубликовать код интерфейса, если это необходимо. Заранее спасибо.

EDIT:

Подумав об этом, я пришел к выводу, что больше интерфейсов лучше (по крайней мере, в моем сценарии). Предположим, что есть x реализаций FileNameLoader, y реализаций LibLoader, z реализаций Plugin. Если я храню эти классы отдельно, я должен написать x + y + z классы реализации. Затем я могу объединить их, чтобы получить любую возможную функциональность. С другой стороны, если бы все эти интерфейсы были в классе Plugin, мне пришлось бы написать x*y*z классы реализации, чтобы получить все возможные функциональные возможности, которые больше x + y + z, учитывая, что для интерфейс. Это только одна сторона этого. Другое преимущество состоит в том, что назначение интерфейсов становится более понятным при наличии большего количества интерфейсов. По крайней мере, я так думаю.

Answer 1

Мои проекты на c ++ обычно состоят из объектов, которые реализуют один или несколько интерфейсов.

Я обнаружил, что этот подход имеет следующие эффекты:

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

Преимущество использования указателей на интерфейсе заключается в том, что вы предоставляете только те функции, которые необходимы другим объектам.

COM активно использует интерфейсы, поскольку его модульная конструкция полезна для IPC (межпроцессное взаимодействие), способствует повторному использованию кода и обеспечивает обратную совместимость.

Microsoft широко использует COM и основывает свои ОС и наиболее важные API (DirectX, DirectShow и т. Д.) На COM по этим причинам, и, хотя это едва ли самая доступная технология, COM не исчезнет в ближайшее время.

Помогут ли они вашей собственной программе? Вам решать. Если вы собираетесь превратить большую часть своего кода в COM-объекты, это, безусловно, правильный подход.

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

Answer 2

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

«Клиенты не должны зависеть от интерфейсов, которые они не используют.»

Более подробно об этом принципе предоставлено в этой статье: http://www.objectmentor.com/resources/articles/isp.pdf

Это часть синергетических принципов SOLID Боба Мартина.

Answer 3

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

Однако, это утверждение беспокоит меня:

Я думал, что прошел дизайн и начал реализацию

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

Answer 4

Наличие одного большого класса, который делает все неправильно.Так что есть один большой интерфейс, который определяет все.

Answer 5

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

Лично мне нравится то, как вы это делаете сейчас.Вы можете заменить на верхнем уровне, или очень конкретные части.