День сто семьдесят первый. #BestPractices
Рекомендации по использованию методов расширения. Окончание
5. Вы можете использовать методы расширения для разделения ответственности, когда вы не хотите внедрять некоторую зависимость в расширяемый тип. Например, вы можете расширить
6. Если вы не уверены, какой тип расширять, не используйте методы расширения. Например, чтобы построить дом из кирпича (
7. Избегайте наличия состояния в ваших методах расширения. Лучше всего вообще избегать наличия состояния в статических классах, потому что это значительно затрудняет тестирование.
Одно из возможных исключений - если вы хотите использовать мемоизацию (кеширование входных и выходных данных для повторного использования результатов). Но это совсем другая история.
8. Избегайте расширения примитивных типов. Есть несколько причин для этого. С одной стороны, будет очень трудно найти метод, который наиболее соответствует примитивному типа. Кроме того, Visual Studio будет всегда показывать этот метод расширения в IntelliSense при каждом использовании этого примитивного типа.
9. Группируйте методы расширения для одного типа в одном классе. Так будет легче найти эти методы в коде. Кроме того, у всех них должно быть много общего, поскольку они относятся к одному и тому же типу.
Замечание: как и в большинстве руководств по стилю кодирования, вышеизложенное является сугубо личным мнением.
Источник: https://michaelscodingspot.com/
Рекомендации по использованию методов расширения. Окончание
5. Вы можете использовать методы расширения для разделения ответственности, когда вы не хотите внедрять некоторую зависимость в расширяемый тип. Например, вы можете расширить
Customer
с помощью такого метода:public static AdjustLastSeen(this Customer customer, TimeZoneManager timeZoneManager) { … }В примере выше, если вы не хотите внедрять зависимость
Customer
от TimeZoneManager
, вы можете добиться этого с помощью метода расширения. Обратите внимание, что в подобных случаях методы расширения могут быть не лучшим вариантом.6. Если вы не уверены, какой тип расширять, не используйте методы расширения. Например, чтобы построить дом из кирпича (
brick
) и раствора (mortar
), я могу расширить кирпич с помощью brick.BuildHouse(mortar)
. Или можно расширить раствор с помощью mortar.BuildHouse(brick)
. Поскольку ни один из методов не является более подходящим, чем другой, вероятно, методом расширения использовать не стоит.7. Избегайте наличия состояния в ваших методах расширения. Лучше всего вообще избегать наличия состояния в статических классах, потому что это значительно затрудняет тестирование.
Одно из возможных исключений - если вы хотите использовать мемоизацию (кеширование входных и выходных данных для повторного использования результатов). Но это совсем другая история.
8. Избегайте расширения примитивных типов. Есть несколько причин для этого. С одной стороны, будет очень трудно найти метод, который наиболее соответствует примитивному типа. Кроме того, Visual Studio будет всегда показывать этот метод расширения в IntelliSense при каждом использовании этого примитивного типа.
9. Группируйте методы расширения для одного типа в одном классе. Так будет легче найти эти методы в коде. Кроме того, у всех них должно быть много общего, поскольку они относятся к одному и тому же типу.
Замечание: как и в большинстве руководств по стилю кодирования, вышеизложенное является сугубо личным мнением.
Источник: https://michaelscodingspot.com/