Дизайн интерфейса? Могу ли я сделать это итеративно? Как я должен обрабатывать изменения в интерфейсе?

Question

Каков наилучший подход для определения интерфейсов в C # или Java? Нужно ли создавать общие или добавлять методы по мере возникновения реальной необходимости?

С уважением, Шринивас

Answer 1

Как только интерфейс определен, он предназначен для , а не . Вы должны задуматься о назначении интерфейса и быть максимально полным.

Если позже вам понадобится добавить метод, вам действительно следует определить новый интерфейс, возможно, интерфейс _V2, с помощью дополнительного метода.

Приложение : Здесь вы найдете несколько хороших рекомендаций по проектированию интерфейса в C # , как часть более масштабной и ценной работы по разработке C # в целом. Как правило, это относится и к Java.

Выдержки:

Хотя большинство API-интерфейсов лучше всего моделировать с использованием классов и структур, в некоторых случаях интерфейсы являются более подходящими или являются единственным вариантом.
DO укажите хотя бы один тип реализация интерфейса. Это помогает проверить дизайн интерфейс. Например, System.Collections.ArrayList является реализация Интерфейс System.Collections.IList.
DO обеспечивает, по крайней мере, одно API, потребляющее каждый интерфейс, который вы определяете (метод принимая интерфейс в качестве параметра или свойство, напечатанное как интерфейс). Это помогает проверить интерфейс дизайн. Например, List.Sort использует интерфейс IComparer.
НЕ добавлять членов в интерфейс, который ранее отправлен. Делать это сломал бы реализации интерфейс. Вы должны создать новый интерфейс, чтобы избежать контроля версий проблемы.

Я рекомендую опираться на общие рекомендации по дизайну шрифтов .

Answer 2

Цитировать Джошуа Блоха:

Если сомневаетесь, оставьте это.

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

В качестве примечания вот отличное интервью с Вэнсом Моррисоном (из команды Microsoft CLR), в котором он упоминает о возможности будущей версии CLR, допускающей "миксины" или интерфейсы с реализациями по умолчанию для своих членов.

Answer 3

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

Теперь, если вы создаете публичный API, с которым будет работать другая команда или клиент (например, плагины, точки расширения или тому подобное), вы должны быть осторожны с тем, что вкладываете в интерфейс. Как уже упоминалось, вам может потребоваться добавить интерфейс типа _V2 в этих случаях. Microsoft сделала с несколькими веб-браузерами COM-интерфейсы.

Руководства, которые Microsoft публикует в Framework Design Guidelines, представляют собой лишь руководство для интерфейса PUBLIC. Не для личных внутренних вещей; хотя многие из них все еще применяются. Знайте, что относится или нет к вашей ситуации.

Ни одно правило не восполнит недостаток здравого смысла.

Answer 4

Добавление методов позже к интерфейсу немедленно нарушает все реализации интерфейса, которые случайно не реализовали эти методы. По этой причине убедитесь, что ваша спецификация интерфейса завершена. Я бы предложил вам начать с (примера) клиента интерфейса, части, которая фактически использует экземпляры классов, реализующих указанный интерфейс. Все, что нужно клиенту, должно быть частью интерфейса (очевидно). Затем создайте (пример) реализацию интерфейса и посмотрите, какие дополнительные методы обычно полезны и доступны (в возможных других реализациях), поэтому они также должны быть частью интерфейса. Проверьте полноту симметрии (например, если есть «openXYZ», также должен быть «closeXYZ». Если есть «addFooBar», должен быть «removeFooBar». И т. Д.) Если возможно, пусть коллега проверит вашу спецификацию.

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

Answer 5

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

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

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

В связи с этим вчера я наткнулся на Google Talk: Как разработать хороший API и почему он важен Джошуа Блох . Он стоял за разработкой и реализацией библиотек Java Collection и тому подобного, и является автором Effective Java .

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

Answer 6

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