День двести сорок седьмой. #BestPractices
Разработка для Расширяемости
Абстракции (Абстрактные типы и интерфейсы)
Абстракция - это тип, который описывает контракт, но не обеспечивает полную реализацию этого контракта. Абстракции обычно реализуются в виде абстрактных классов или интерфейсов и содержат чёткую справочную документацию, описывающую необходимую семантику типов, реализующих контракт. Некоторые из наиболее важных абстракций в .NET Framework включают
Вы можете расширять фреймворки, реализовав конкретный тип, который поддерживает контракт абстракции, и используя этот конкретный тип с API-интерфейсами фреймворка, работающими с использованием абстракции.
Содержательную и полезную абстракцию, способную выдержать испытание временем, очень сложно спроектировать. Основная трудность - создать правильный набор членов, не больше и не меньше. Если абстракция имеет слишком много членов, она становится трудной или даже невозможной для реализации. Если у неё слишком мало членов для обещанной функциональности, она становится бесполезной во многих нужных сценариях.
Слишком большое количество абстракций в фреймворке также негативно влияет на удобство использования фреймворка. Часто довольно трудно понять абстракцию, не понимая, как она вписывается в общую картину конкретных реализаций и API, работающих с абстракцией. Кроме того, названия абстракций и их члены обязательно являются слишком общими, что часто делает их непонятными без предварительного глубокого разбора контекста их использования.
Однако абстракции обеспечивают чрезвычайно мощную расширяемость, которую другие механизмы расширяемости часто не могут предоставить. Они лежат в основе многих архитектурных шаблонов, таких как подключаемые модули, инверсия управления (IoC), конвейеры и т. д. Они также чрезвычайно важны для тестируемости фреймворков. Хорошие абстракции позволяют избавиться от тяжелых зависимостей для проведения модульного тестирования. Таким образом абстракции отвечают за богатство современных объектно-ориентированных структур.
❌ ИЗБЕГАЙТЕ предоставления абстракций, если они не протестированы путем разработки нескольких конкретных реализаций и API, использующих эти абстракции.
✅ НЕОБХОДИМО выбрать между абстрактным классом и интерфейсом при разработке абстракции.
⚠️ РАССМОТРИТЕ предоставление справочных тестов для конкретных реализаций абстракций. Такие тесты должны позволять пользователям проверять, правильно ли их реализации реализуют контракт.
Источник: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/
Разработка для Расширяемости
Абстракции (Абстрактные типы и интерфейсы)
Абстракция - это тип, который описывает контракт, но не обеспечивает полную реализацию этого контракта. Абстракции обычно реализуются в виде абстрактных классов или интерфейсов и содержат чёткую справочную документацию, описывающую необходимую семантику типов, реализующих контракт. Некоторые из наиболее важных абстракций в .NET Framework включают
Stream, IEnumerable<T> и Object.Вы можете расширять фреймворки, реализовав конкретный тип, который поддерживает контракт абстракции, и используя этот конкретный тип с API-интерфейсами фреймворка, работающими с использованием абстракции.
Содержательную и полезную абстракцию, способную выдержать испытание временем, очень сложно спроектировать. Основная трудность - создать правильный набор членов, не больше и не меньше. Если абстракция имеет слишком много членов, она становится трудной или даже невозможной для реализации. Если у неё слишком мало членов для обещанной функциональности, она становится бесполезной во многих нужных сценариях.
Слишком большое количество абстракций в фреймворке также негативно влияет на удобство использования фреймворка. Часто довольно трудно понять абстракцию, не понимая, как она вписывается в общую картину конкретных реализаций и API, работающих с абстракцией. Кроме того, названия абстракций и их члены обязательно являются слишком общими, что часто делает их непонятными без предварительного глубокого разбора контекста их использования.
Однако абстракции обеспечивают чрезвычайно мощную расширяемость, которую другие механизмы расширяемости часто не могут предоставить. Они лежат в основе многих архитектурных шаблонов, таких как подключаемые модули, инверсия управления (IoC), конвейеры и т. д. Они также чрезвычайно важны для тестируемости фреймворков. Хорошие абстракции позволяют избавиться от тяжелых зависимостей для проведения модульного тестирования. Таким образом абстракции отвечают за богатство современных объектно-ориентированных структур.
❌ ИЗБЕГАЙТЕ предоставления абстракций, если они не протестированы путем разработки нескольких конкретных реализаций и API, использующих эти абстракции.
✅ НЕОБХОДИМО выбрать между абстрактным классом и интерфейсом при разработке абстракции.
⚠️ РАССМОТРИТЕ предоставление справочных тестов для конкретных реализаций абстракций. Такие тесты должны позволять пользователям проверять, правильно ли их реализации реализуют контракт.
Источник: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/