Ответ.

Появление методов расширения связано с необходимостью добавлять новые функции к уже существующим типам данных (особенно библиотечным и внешним), не изменяя исходного кода этих типов. Это особенно актуально в современных .NET-приложениях, где нужны дополнительные удобства, но нет доступа к модификации исходных классов.

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

Решение — методы расширения. В Visual Basic они объявляются как модули со статическими методами, помеченными атрибутом <Extension>. Первый параметр метода всегда указывает на расширяемый тип, это даёт возможность обращаться к методу как к обычному члену объекта.

Пример кода:

Imports System.Runtime.CompilerServices

Module StringExtensions
    <Extension>
    Public Function ToTitleCase(ByVal str As String) As String
        If String.IsNullOrEmpty(str) Then Return str
        Return Char.ToUpper(str(0)) & str.Substring(1).ToLower()
    End Function
End Module

' Использование:
Dim s As String = "visual basic"
Console.WriteLine(s.ToTitleCase()) ' Visual basic

Ключевые особенности:

Методы расширения видны и доступны, как методы экземпляра классов.
Не нарушают принцип инкапсуляции целевых типов.
Подходят только для статических методов в модулях.

Вопросы с подвохом.

Можно ли к методу расширения обратиться через имя класса, а не экземпляра?

Да, метод расширения можно вызвать и через имя класса-расширения как статический метод, просто явно указывая первый (this/Me) параметр.

Пример кода:

StringExtensions.ToTitleCase("test string")

Можно ли переопределить (Override) поведение системных методов через Extension Methods?

Нет, методы расширения не переопределяют существующие методы экземпляра. При совпадении имён будет вызван родной метод типа.

Могут ли методы расширения иметь переменное число аргументов (ParamArray), например, для строк?

Да, можно использовать ParamArray в методах расширения, как и в обычных статических методах.

Типовые ошибки и анти-паттерны

Забывают подключить модуль расширений через Imports, из-за чего методы не видны.
Не используют проверки на null/empty для строк.
Дают слишком общие или конфликтующие имена методов, что может вызвать путаницу.

Пример из жизни

Негативный кейс

В большом проекте для каждого типа создаются собственные методы расширения с перекрывающимися именами и разной логикой, без единого стиля.

Плюсы:

Гибкость, не мешает основной функциональности класса.

Минусы:

Непоследовательность, повышение сложности поддержки, частые коллизии имен.

Позитивный кейс

В модуле собираются только универсальные и хорошо документированные расширения для стандартных операций над типами. Имя каждого метода четко указывает его назначение.