Абстракции (абстрактные типы и интерфейсы)
Абстракция — это тип, описывающий контракт, но не предоставляющий его полную реализацию. Абстракции, как правило, реализуются как абстрактные классы или интерфейсы, и они поставляются с четко определенным набором справочной документации, описывающей необходимую семантику типов, реализующих контракт. К некоторым из наиболее важных абстракций в .NET Framework относятся Stream, IEnumerable<T> и Object.
Платформы можно расширять, реализуя конкретный тип, поддерживающий контракт абстракции, и используя этот конкретный тип с API-интерфейсами платформы, которые используют абстракцию (работают с ней).
Содержательную и универсальную абстракцию, способную выдержать проверку временем, очень сложно спроектировать. Основная сложность заключается в получении правильного набора элементов — ни больше, ни меньше. Если абстракция содержит слишком много элементов, реализовать ее сложно либо даже невозможно. Если у вас слишком мало элементов для обещанной функции, она становится бесполезной во многих интересных сценариях.
Слишком большое количество абстракций в платформе также отрицательно сказывается на удобстве использования платформы. Часто бывает довольно трудно понять абстракцию, не зная, как она впишется в более полную картину конкретных реализаций и API-интерфейсов, работающих с абстракцией. Кроме того, имена абстракций и их элементов обязательно являются абстрактными, из-за чего их часто трудно или вовсе невозможно понять без более широкого контекста их использования.
Тем не менее абстракции обеспечивают весьма впечатляющую расширяемость, которую часто не могут обеспечить другие механизмы расширяемости. Они являются основой многих архитектурных шаблонов, таких как подключаемые модули, инверсия управления, конвейеры и т. д. Они также чрезвычайно важны для тестирования платформ. Оптимальные абстракции позволяют создать заглушки для сложных зависимостей при модульном тестировании. В целом абстракции отвечают за насыщенность современных объектно-ориентированных платформ.
❌ НЕ следует предоставлять абстракции, если они не проверяются путем разработки нескольких конкретных реализаций и API-интерфейсов, использующих абстракции.
✔️ При проектировании абстракции ПРИНИМАЙТЕ решение взвешенно, выбирая между абстрактным классом и интерфейсом.
✔️ Рассмотрите возможность предоставления сравнительных проверок для конкретных реализаций абстракций. Такие проверки должны дать пользователям возможность узнать, правильно ли реализован контракт в их реализациях.
Фрагменты: © Корпорация Майкрософт (Microsoft Corporation), 2005, 2009. Все права защищены.
Перепечатано с разрешения Pearson Education, Inc. из книги Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек .NET (2-е издание), авторы: Кржиштоф Цвалина (Krzysztof Cwalina) и Брэд Абрамс (Brad Abrams). Книга опубликована 22 октября 2008 г. издательством Addison-Wesley Professional в рамках серии, посвященной разработке для Microsoft Windows.