оценка затрат / выгод от использования методов расширения в C # => 3.0 [закрыто]

При каких обстоятельствах (сценарии использования) вы предпочитаете писать расширение, а не подклассифицировать объект?

<полное раскрытие: я не сотрудник MS; Я не знаю Мицу Фурота лично; Я знаю автора библиотеки Componax с открытым исходным кодом, упомянутой здесь, но у меня нет никаких деловых отношений с ним; Я не создаю или не планирую создавать какой-либо коммерческий продукт с использованием расширений: в итоге: этот пост из чисто интеллектуального интереса, связанного с моей попыткой (постоянно) узнавать о «лучших практиках»>

Я нахожу идею методов расширения «крутой», и, очевидно, вы можете делать с ними «далеко» вещи, как во многих примерах, которые вы можете в сообщениях в блоге Мицу Фуроты (MS)текст ссылки.

Личный друг написал библиотеку Componax с открытым исходным кодомтекст ссылкии там есть несколько замечательных удобств; но он полностью командует своей небольшой компанией, полностью контролируя правила кода, и каждая строка кода «проходит через его руки».

Хотя это спекуляция с моей стороны: я думаю / думаю, что другие проблемы могут возникнуть в средне-крупной команде разработчиков программного обеспечения при использовании расширений.

Глядя на рекомендации MS потекст ссылки, ты находишь :

В общем, вы, вероятно, будете вызывать методы расширения гораздо чаще, чем реализовывать свои собственные. ... В общем, мы рекомендуем применять методы расширения экономно и только тогда, когда это необходимо. Когда это возможно, клиентский код, который должен расширять существующий тип, должен делать это путем создания нового типа, производного от существующего типа. Для получения дополнительной информации см. Наследование (Руководство по программированию в C #). ... Когда компилятор встречает вызов метода, он сначала ищет совпадение в методах экземпляра типа. Если совпадений не найдено, он будет искать любые методы расширения, определенные для этого типа, и связываться с первым найденным методом расширения.

И у миссистекст ссылки :

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

Факторы, которые кажутся мне очевидными, включают:

Я предполагаю, что вы не напишете расширение, если не ожидаете, что оно будет использоваться очень часто и очень часто. С другой стороны: не могли бы вы сказать то же самое о подклассе?

Зная, что мы можем скомпилировать их в отдельный dll, добавить скомпилированный dll и сослаться на него, а затем использовать расширения: это «круто», но это «уравновешивает» затраты, присущие компилятору, который сначала нужно проверить, чтобы увидеть если методы экземпляра определены как описано выше. Или стоимость, в случае «конфликта имен», использования статических методов вызова, чтобы убедиться, что ваше расширение вызывается, а не определение экземпляра?

Как частое использование расширений повлияет на производительность во время выполнения или использование памяти: я понятия не имею.

Поэтому я был бы признателен за ваши мысли или знание того, как / когда вы используете или не используете расширения по сравнению с подклассами.

спасибо билл

Ответы на вопрос(4)

Ваш ответ на вопрос