Разработка интерфейса
Примечание.
Это содержимое перепечатывается разрешением Pearson Education, Inc. из руководства по проектированию платформы: соглашения, идиомы и шаблоны для повторно используемых библиотек .NET, 2-го выпуска. Этот выпуск был опубликован в 2008 году, и книга с тех пор была полностью пересмотрена в третьем выпуске. Некоторые сведения на этой странице могут быть устаревшими.
Хотя большинство API-интерфейсов лучше всего моделировать с помощью классов и структур, бывают случаи, когда интерфейсы подходят больше или являются единственным вариантом.
Среда CLR не поддерживает множественное наследование (т. е. классы CLR не могут наследовать от нескольких базовых классов), но позволяют типам реализовать один или несколько интерфейсов в дополнение к наследованию от базового класса. Поэтому интерфейсы часто используются для получения эффекта множественного наследования. Например, IDisposable является интерфейсом, который позволяет типам поддерживать возможность удаления независимо от любых других иерархий наследования, в которых они хотят участвовать.
Другая ситуация, при которой необходимо определить интерфейс, — это создание общего интерфейса, который может поддерживаться несколькими типами, включая некоторые типы значений. Типы значений не могут наследовать от типов, отличных от ValueType, но они могут реализовывать интерфейсы, поэтому использование интерфейса — это единственный доступный вариант для предоставления общего базового типа.
✔ ОПРЕДЕЛИТЕ интерфейс, если требуется, чтобы набор типов, включая типы значений, поддерживал некоторые общие API-интерфейсы.
✔️ Рассмотрите возможность определения интерфейса, если требуется поддержка его функциональных возможностей для типов, которые уже наследуются от другого типа.
❌ Избегайте использования интерфейсов метки (интерфейсы без элементов).
Если необходимо пометить класс как имеющий определенную характеристику (метку), как правило, используйте настраиваемый атрибут, а не интерфейс.
✔ ПРЕДОСТАВЬТЕ по крайней мере один тип, который является реализацией интерфейса.
Это помогает проверить структуру интерфейса. Например, List<T> — это реализация интерфейса IList<T>.
✔️ ПРЕДОСТАВЬТЕ по крайней мере один API-интерфейс, который использует каждый определяемый интерфейс (метод, принимающий интерфейс в качестве параметра или свойства, типизированного как интерфейс).
Это помогает проверить структуру интерфейса. Например, List<T>.Sort использует интерфейс System.Collections.Generic.IComparer<T>.
❌ НЕ добавляйте элементы к интерфейсу, который уже отправлен.
Это приведет к нарушению реализаций интерфейса. Чтобы избежать проблем с управлением версиями, необходимо создать новый интерфейс.
За исключением ситуаций, описанных в этих рекомендациях, в целом при проектировании многократно используемых библиотек с управляемым кодом следует выбирать классы, а не интерфейсы.
Фрагменты: © Корпорация Майкрософт (Microsoft Corporation), 2005, 2009. Все права защищены.
Перепечатано с разрешения Pearson Education, Inc. из книги Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек .NET (2-е издание), авторы: Кржиштоф Цвалина (Krzysztof Cwalina) и Брэд Абрамс (Brad Abrams). Книга опубликована 22 октября 2008 г. издательством Addison-Wesley Professional в рамках серии, посвященной разработке для Microsoft Windows.