Экстеншн что это такое в программировании

С# extension methods: простой, но полезный пример

Что делает данный код? Он расширяет все классы реализующие интерфейс IList методом ListToString, который позволяет получить перечисление элементов списка через запятую в виде строки. Для расширения функционала стандартного интерфейса всего-то и нужно теперь подключить пространство имен SampleNS. (Комментарий: благодаря весьма полезному замечанию easyman, пример переписан с использованием класса StringBuilder)

Вот пример использования:

var _list = DataContextORM.ExecuteQuery("Select name from products").ToList(); string result = _list.ListToString();

Этот пример получит в _list список названий всех продуктов, а затем присвоит строку с перечислением названий через запятую переменной result.

PS: перенес из персонального блога

C sharp
extension methods

Расширения (extensions)

Kotlin позволяет расширять класс путём добавления нового функционала без необходимости наследования от такого класса и использования паттернов, таких как Decorator. Это реализовано с помощью специальных выражений, называемых расширения.

Например, вы можете написать новые функции для класса из сторонней библиотеки, которую вы не можете изменить. Такие функции можно вызывать обычным способом, как если бы они были методами исходного класса. Этот механизм называется функцией расширения. Существуют также свойства расширения, которые позволяют определять новые свойства для существующих классов.

Функции-расширения

Для того чтобы объявить функцию-расширение, укажите в качестве префикса расширяемый тип, то есть тип, который мы расширяем. Следующий пример добавляет функцию swap к MutableList :

fun MutableList.swap(index1: Int, index2: Int) < val tmp = this[index1] // 'this' даёт ссылку на список this[index1] = this[index2] this[index2] = tmp >

Ключевое слово this внутри функции-расширения соотносится с объектом расширяемого типа (этот тип ставится перед точкой). Теперь мы можем вызывать такую функцию в любом MutableList .

val list = mutableListOf(1, 2, 3) list.swap(0, 2) // 'this' внутри 'swap()' будет содержать значение 'list'

`, and you can make it generic: —>

Следующая функция имеет смысл для любого MutableList , и вы можете сделать её обобщённой:

fun MutableList.swap(index1: Int, index2: Int) < val tmp = this[index1] // 'this' относится к списку this[index1] = this[index2] this[index2] = tmp >

Вам нужно объявлять обобщённый тип-параметр перед именем функции для того, чтобы он был доступен в получаемом типе-выражении. См. Обобщения.

Расширения вычисляются статически

Расширения на самом деле не проводят никаких модификаций с классами, которые они расширяют. Объявляя расширение, вы создаёте новую функцию, а не новый член класса. Такие функции могут быть вызваны через точку, применимо к конкретному типу.

Расширения имеют статическую диспетчеризацию: это значит, что вызванная функция-расширение определяется типом её выражения, из которого она вызвана, а не типом выражения, вычисленным в ходе выполнения программы, как при вызове виртуальных функций.

open class Shape class Rectangle: Shape() fun Shape.getName() = "Shape" fun Rectangle.getName() = "Rectangle" fun printClassName(s: Shape) < println(s.getName()) >printClassName(Rectangle())

Этот пример выведет нам Shape на экран потому, что вызванная функция-расширение зависит только от объявленного параметризованного типа s , который является Shape классом.

Если в классе есть и функция-член, и функция-расширение с тем же возвращаемым типом, таким же именем и применяется с такими же аргументами, то функция-член имеет более высокий приоритет.

class Example < fun printFunctionType() < println("Class method") >> fun Example.printFunctionType() < println("Extension function") >Example().printFunctionType()

Этот код выведет Class method.

Однако для функций-расширений совершенно нормально перегружать функции-члены, которые имеют такое же имя, но другую сигнатуру.

class Example < fun printFunctionType() < println("Class method") >> fun Example.printFunctionType(i: Int) < println("Extension function #$i") >Example().printFunctionType(1)

Обращение к Example().printFunctionType(1) выведет на экран надпись Extension function #1.

Расширение null-допустимых типов

Обратите внимание, что расширения могут быть объявлены для null-допустимых типов. Такие расширения могут ссылаться на переменные объекта, даже если значение переменной равно null и есть возможность провести проверку this == null внутри тела функции.

Благодаря этому метод toString() в Kotlin вызывается без проверки на null : она проходит внутри функции-расширения.

fun Any?.toString(): String < if (this == null) return "null" // после проверки на null, `this` автоматически приводится к не-null типу, // поэтому toString() обращается (ориг.: resolves) к функции-члену класса Any return toString() >

Свойства-расширения

Аналогично функциям, Kotlin поддерживает расширения свойств.

val List.lastIndex: Int get() = size - 1

Since extensions do not actually insert members into classes, there’s no efficient way for an extension > property to have a [backing field](properties.md#backing-fields). This is why _initializers are not allowed for > extension properties_. Their behavior can only be defined by explicitly providing getters/setters. —>

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

val House.number = 1 // ошибка: запрещено инициализировать значения // в свойствах-расширениях

Расширения для вспомогательных объектов (ориг.: companion object extensions)

Если у класса есть вспомогательный объект, вы также можете определить функции и свойства расширения для такого объекта. Как и обычные члены вспомогательного объекта, их можно вызывать, используя в качестве определителя только имя класса.

class MyClass < companion object < >// называется "Companion" > fun MyClass.Companion.printCompanion()

Область видимости расширений

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

package org.example.declarations fun List.getLongestString() < /*. */>

Для того, чтобы использовать такое расширение вне пакета, в котором оно было объявлено, импортируйте его на месте вызова.

package org.example.usage import org.example.declarations.getLongestString fun main()

См. Импорт для более подробной информации.

Объявление расширений в качестве членов класса

Внутри класса вы можете объявить расширение для другого класса. Внутри такого объявления существует несколько неявных объектов-приёмников (ориг.: implicit receivers), доступ к членам которых может быть произведён без квалификатора. Экземпляр класса, в котором расширение объявлено, называется диспетчером приёмников (ориг.: dispatch receiver), а экземпляр класса, для которого вызывается расширение, называется приёмником расширения (ориг.: extension receiver).

class Host(val hostname: String) < fun printHostname() < print(hostname) >> class Connection(val host: Host, val port: Int) < fun printPort() < print(port) >fun Host.printConnectionString() < printHostname() // вызывает Host.printHostname() print(":") printPort() // вызывает Connection.printPort() >fun connect() < /*. */ host.printConnectionString() // вызов функции-расширения >> fun main() < Connection(Host("kotl.in"), 443).connect() // Host("kotl.in").printConnectionString() // ошибка, функция расширения недоступна вне подключения >

В случае конфликта имён между членами классов диспетчера приёмников и приёмников расширения, приоритет имеет приёмник расширения. Чтобы обратиться к члену класса диспетчера приёмников, можно использовать синтаксис this с квалификатором.

class Connection < fun Host.getConnectionString() < toString() // вызывает Host.toString() this@Connection.toString() // вызывает Connection.toString() >>

Расширения, объявленные как члены класса, могут иметь модификатор видимости open и быть переопределены в унаследованных классах. Это означает, что диспечеризация таких функций является виртуальной по отношению к типу диспетчера приёмников, но статической по отношению к типам приёмников расширения.

open class Base < >class Derived : Base() < >open class BaseCaller < open fun Base.printFunctionInfo() < println("Base extension function in BaseCaller") >open fun Derived.printFunctionInfo() < println("Derived extension function in BaseCaller") >fun call(b: Base) < b.printFunctionInfo() // вызов функции расширения >> class DerivedCaller: BaseCaller() < override fun Base.printFunctionInfo() < println("Base extension function in DerivedCaller") >override fun Derived.printFunctionInfo() < println("Derived extension function in DerivedCaller") >> fun main() < BaseCaller().call(Base()) // "Base extension function in BaseCaller" DerivedCaller().call(Base()) // "Base extension function in DerivedCaller" - приемник отправки является виртуальным DerivedCaller().call(Derived()) // "Base extension function in DerivedCaller" - приемник расширения является статическим >

Примечание о видимости

Расширения используют те же модификаторы видимости как и обычные функции, объявленные в той же области видимости. Например:

Расширение, объявленное на верхнем уровне файла, имеет доступ к другим private объявлениям верхнего уровня в том же файле;
Если расширение объявлено вне своего типа приёмника, оно не может получить доступ к private или protected членам приёмника.

Extension methods: stop the madness!

Давным-давно, когда компьютеры были большими, программисты — бородатыми, а код — процедурным, на Земле царила идиллия. Программисты писали простой и понятный код, не задумываясь о соответствии его догмам. Да и не было тогда никаких догм. Каждый из этих одиноких ковбоев был творцом в своём собственном мире. Каждый выражал свою мысль элегантно и ёмко; каждая строка кода была произведением искусства, достойным безграничного восхищения. Иначе и быть не могло: вычислительные ресурсы были настолько скудны, что никому и в голову не приходило потратить их только на то, чтобы код выглядел красиво.

Однако время шло, и непобедимая машина технического прогресса неумолимо наращивала производительность железа. В один прекрасный день люди поняли, что они могут писать неоптимизированный код, и им за это ничего не будет! Вычислительные мощности выросли настолько, что компьютерам было уже всё равно, что выполнять: выверенный до последней машинной инструкции код, или код, написанный студентом-первокурсником за сосиску в тесте. Это был поистине переломный момент, после которого, как грибы после дождя, стали появляться новые концепции и методики программирования.

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

Давайте рассмотрим элементарный пример, просто для того, чтобы вспомнить, что же из себя представляет ООП (а именно, один из его аспектов — инкапсуляция).

public class Cat < public float CuddlynessFactor < get; private set; >public Cat(float cuddlynessFactor) < this.CuddlynessFactor = cuddlynessFactor; >public void Purr() < Console.WriteLine("Purr!"); >public void HitTheWall() < Console.WriteLine("Fu**ing meow. "); >> public class Dog < public float TeethSharpness < get; private set; >; public Dog(float teethSharpness) < this.TeethSharpness = teethSharpness; >public void Bark() < Console.WriteLine("Bark!"); >public void Bite(Human target) < target.Leg.DoDamage(DamageLevel.Substantial); >>

Как видите, мы определили два простейших класса: Cat и Dog. Каждый из этих классов является репрезентацией объекта из реальной жизни и обладает некоторыми свойствами этих объектов, релевантными в контексте нашей системы. Эти объекты умеют каким-то образом взаимодействовать с окружающей средой (методы) и обладают какими-то качествами (поля). Суть инкапсуляции заключается в том, что каждый объект содержит в себе все методы и данные, необходимые для его функционирования. Кроме того, объекты не содержат методов или свойств, которые не имеют отношения к их поведению (ещё бы, какой собаке придёт в голову разогнаться по паркету и на полной скорости впилиться в стену?).

Теперь представим, что мы хотим произвести какие-то действия над этими объектами. Например, мы хотим сделать из собаки кошку. Это поведение не относится ни к одному из перечисленных классов, так как никакая собака в здравом уме не станет трансмогрифицироваться© в кошку. Для этой цели мы можем создать сторонний статический класс, содержащий нужное поведение.

public static class Transmogrificator < public static Cat DogToCat(Dog dog) < return new Cat(Math.Sqrt(dog.TeethSharpness) * 42); >>

Вуаля! Используя новый класс, мы с лёгкостью можем превратить собаку в кошку!

public void Test()

Sweet! И вот теперь мы вплотную подходим к концепции Extension methods, которую Microsoft не так давно ввела в .NET. По задумке авторов, extension methods должны применяться там, где целевой класс не имеет какой-то функциональности, которая ему очевидно нужна (или, по крайней мере, может являться его частью). Вот что говорит по поводу методов расширения в. и у. MSDN:

In general, you will probably be calling extension methods far more often than implementing your own.
[. ]
In general, we recommend that you implement extension methods sparingly and only when you have to. Whenever possible, client code that must extend an existing type should do so by creating a new type derived from the existing type.
[. ]
When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.

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

Теперь давайте посмотрим, что случится, если мы модифицируем наш пример, сделав метод DogToCat методом расширения.

public void Test()

Нарушается один из основополагающих принципов ООП — инкапсуляция. Способность превратиться в кошку — это не способность, принадлежащая собаке. Это способность доброго доктора с бензопилой и в халате, заляпанном кровью. Апологеты методов расширения будут говорить, что формально инкапсуляция не нарушена, так как реализация метода по-прежнему находится в статическом классе. Однако представьте себя на месте нового разработчика, который разбирается с чужим кодом. Для него совершенно логичным будет заключить, что метод DogToCat принадлежит именно типу Dog! Вы только представьте горечь разочарования, которую он испытает, когда узнает, что на самом деле это extension method. Вы когда-нибудь чувствовали себя обманутым? Возможно, бедолаге даже потребуются услуги психотерапевта.
Непонятно, где находятся различные методы расширения, предназначенные для одного и того же класса. Непонятно, как их подключать. В то время, как при использовании статического класса у нас есть хорошо сформированное имя, которое обычно отражает логику работы этого класса, для методов расширения у нас есть только догадки. Чтобы подключить нужный метод, нам нужно прописать namespace, имя которого может оказаться совсем неочевидным. Да, я слышу вас, поклонники R#. Я и сам очень люблю этот инструмент, но в данном случае он является лишь обезболивающим, которое маскирует боль в ноге, поражённой гангреной. Изначальная неочевидность подключения методов расширения кагбэ намекает нам, но мы предпочитаем не слушать доводов разума и вместо этого закидываемся очередной дозой морфина.

UPD: Видимо, растекшись мыслью по древу, я недостаточно чётко выразил суть статьи. А суть заключается вот в чём: я призываю не использовать Extension methods для расширения функционала классов, находящихся в том же проекте. Написать расширение для класса в скомпиленной сборке, к исходникам которой у вас нет доступа — это хорошо. Применять расширения для создания LINQ-подобного синтаксиса — это очень хорошо. А вот создавать классы, и в этом же проекте навешивать на них дополнительный функционал с помощью Extensions — это очень, очень плохо.

Методы расширения (Руководство по программированию в C#)

Методы расширения позволяют «добавлять» методы в существующие типы без создания нового производного типа, перекомпиляции и иного изменения первоначального типа. Методы расширения представляют собой разновидность статического метода, но вызываются так же, как методы экземпляра в расширенном типе. Для клиентского кода, написанного на языках C#, F# и Visual Basic, нет видимого различия между вызовом метода расширения и вызовом методов, определенных в типе.

Пример OrderBy

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

class ExtensionMethods2 < static void Main() < int[] ints = [10, 45, 15, 39, 21, 26]; var result = ints.OrderBy(g =>g); foreach (var i in result) < System.Console.Write(i + " "); >> > //Output: 10 15 21 26 39 45

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

В приведенном ниже примере показан метод расширения, определенный для класса System.String. Этот метод определяется внутри невложенного, неуниверсального статического класса:

namespace ExtensionMethods < public static class MyExtensions < public static int WordCount(this string str) < return str.Split(new char[] < ' ', '.', '?' >, StringSplitOptions.RemoveEmptyEntries).Length; > > >

Метод расширения WordCount можно ввести в область действия с помощью следующей директивы using :

using ExtensionMethods;

Его можно вызвать из приложения с помощью следующего синтаксиса:

string s = "Hello Extension Methods"; int i = s.WordCount();

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

Класс MyExtensions и метод WordCount являются static , и доступ к ним можно получить так же, как ко всем остальным элементам static . Метод WordCount может быть вызван так же, как другие методы static , следующим образом:

string s = "Hello Extension Methods"; int i = MyExtensions.WordCount(s);

В приведенном выше коде C#:

Объявляет и назначает новый string с именем s и значением «Hello Extension Methods» .
Вызывает MyExtensions.WordCount с учетом аргумента s

Вообще, обычно гораздо чаще вызываются методы расширения, чем реализуются собственные методы. Так как методы расширения вызываются с помощью синтаксиса обращения к методу экземпляра, для использования их из клиентского кода специальные знания не требуются. Чтобы включить методы расширения для определенного типа, необходимо просто добавить директиву using для пространства имен, в котором эти методы определяются. Например, чтобы использовать стандартные операторы запроса, нужно добавить в код следующую директиву using :

using System.Linq;

(Возможно, вам также потребуется добавить ссылку на System.Core.dll.) Вы заметите, что стандартные операторы запросов теперь отображаются в IntelliSense в качестве дополнительных методов, доступных для большинства IEnumerable типов.

Привязка методов расширения во время компиляции

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

Пример

В следующем примере демонстрируются правила, которые компилятор C# соблюдает при определении того, к чему необходимо привязать вызов метода — к методу экземпляра типа или к методу расширения. Статический класс Extensions содержит методы расширения, определяемые для любого типа, реализующего интерфейс IMyInterface . Все три класса — A , B и C — реализуют этот интерфейс.

Метод расширения MethodB никогда не вызывается, потому что его имя и сигнатура точно совпадают с методами, уже реализованными этими классами.

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

// Define an interface named IMyInterface. namespace DefineIMyInterface < public interface IMyInterface < // Any class that implements IMyInterface must define a method // that matches the following signature. void MethodB(); >> // Define extension methods for IMyInterface. namespace Extensions < using System; using DefineIMyInterface; // The following extension methods can be accessed by instances of any // class that implements IMyInterface. public static class Extension < public static void MethodA(this IMyInterface myInterface, int i) < Console.WriteLine ("Extension.MethodA(this IMyInterface myInterface, int i)"); >public static void MethodA(this IMyInterface myInterface, string s) < Console.WriteLine ("Extension.MethodA(this IMyInterface myInterface, string s)"); >// This method is never called in ExtensionMethodsDemo1, because each // of the three classes A, B, and C implements a method named MethodB // that has a matching signature. public static void MethodB(this IMyInterface myInterface) < Console.WriteLine ("Extension.MethodB(this IMyInterface myInterface)"); >> > // Define three classes that implement IMyInterface, and then use them to test // the extension methods. namespace ExtensionMethodsDemo1 < using System; using Extensions; using DefineIMyInterface; class A : IMyInterface < public void MethodB() < Console.WriteLine("A.MethodB()"); >> class B : IMyInterface < public void MethodB() < Console.WriteLine("B.MethodB()"); >public void MethodA(int i) < Console.WriteLine("B.MethodA(int i)"); >> class C : IMyInterface < public void MethodB() < Console.WriteLine("C.MethodB()"); >public void MethodA(object obj) < Console.WriteLine("C.MethodA(object obj)"); >> class ExtMethodDemo < static void Main(string[] args) < // Declare an instance of class A, class B, and class C. A a = new A(); B b = new B(); C c = new C(); // For a, b, and c, call the following methods: // -- MethodA with an int argument // -- MethodA with a string argument // -- MethodB with no argument. // A contains no MethodA, so each call to MethodA resolves to // the extension method that has a matching signature. a.MethodA(1); // Extension.MethodA(IMyInterface, int) a.MethodA("hello"); // Extension.MethodA(IMyInterface, string) // A has a method that matches the signature of the following call // to MethodB. a.MethodB(); // A.MethodB() // B has methods that match the signatures of the following // method calls. b.MethodA(1); // B.MethodA(int) b.MethodB(); // B.MethodB() // B has no matching method for the following call, but // class Extension does. b.MethodA("hello"); // Extension.MethodA(IMyInterface, string) // C contains an instance method that matches each of the following // method calls. c.MethodA(1); // C.MethodA(object) c.MethodA("hello"); // C.MethodA(object) c.MethodB(); // C.MethodB() >> > /* Output: Extension.MethodA(this IMyInterface myInterface, int i) Extension.MethodA(this IMyInterface myInterface, string s) A.MethodB() B.MethodA(int i) B.MethodB() Extension.MethodA(this IMyInterface myInterface, string s) C.MethodA(object obj) C.MethodA(object obj) C.MethodB() */

Общие варианты использования

Функциональные возможности коллекций

Функциональные возможности конкретного слоя

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

public class DomainEntity < public int Id < get; set; >public string FirstName < get; set; >public string LastName < get; set; >> static class DomainEntityExtensions < static string FullName(this DomainEntity value) =>$" "; >

Расширение предопределенных типов

Если необходимо создать многократно используемые функциональные возможности, вы можете расширить существующий тип, например тип .NET или CLR, чтобы не создавать дополнительные объекты. Например, если методы расширения не используются, можно создать класс Engine или Query , чтобы выполнить запрос к SQL Server, который можно вызвать из нескольких расположений в коде. Однако вместо этого можно расширить класс System.Data.SqlClient.SqlConnection с помощью методов расширения, чтобы выполнить этот запрос из любого расположения, где установлено подключение с SQL Server. В качестве второго примера можно привести добавление общих функциональных возможностей в класс System.String, расширение возможностей обработки данных объектов System.IO.File и System.IO.Stream, а также объектов System.Exception для функциональных возможностей обработки конкретных ошибок. Сценарии использования ограничиваются только воображением и здравым смыслом.

Расширение предопределенных типов с помощью типов struct может быть сложным, так как они передаются методам по значению. Это означает, что любые изменения структуры вносятся в ее копию. Эти изменения не отображаются после выхода из метода расширения. Модификатор можно добавить ref в первый аргумент, что делает его методом ref расширения. Ключевое слово ref может отображаться до или после this ключевое слово без семантических различий. ref Добавление модификатора указывает, что первый аргумент передается по ссылке. Это позволяет создавать методы расширения, изменяющие состояние расширенной структуры (обратите внимание, что частные члены недоступны). В качестве первого параметра метода расширения разрешены только типы значений или универсальные типы, ограниченные структурой (см struct . ограничение для получения дополнительных сведений ref ). В следующем примере показано, как использовать ref метод расширения для непосредственного изменения встроенного типа без необходимости переназначить результат или передать его через функцию с ref помощью ключевое слово:

public static class IntExtensions < public static void Increment(this int number) =>number++; // Take note of the extra ref keyword here public static void RefIncrement(this ref int number) => number++; > public static class IntProgram < public static void Test() < int x = 1; // Takes x by value leading to the extension method // Increment modifying its own copy, leaving x unchanged x.Increment(); Console.WriteLine($"x is now "); // x is now 1 // Takes x by reference leading to the extension method // RefIncrement changing the value of x directly x.RefIncrement(); Console.WriteLine($"x is now "); // x is now 2 > >

В следующем примере показаны ref методы расширения для определяемых пользователем типов структур:

public struct Account < public uint id; public float balance; private int secret; >public static class AccountExtensions < // ref keyword can also appear before the this keyword public static void Deposit(ref this Account account, float amount) < account.balance += amount; // The following line results in an error as an extension // method is not allowed to access private members // account.secret = 1; // CS0122 >> public static class AccountProgram < public static void Test() < Account account = new() < balance = 100f >; Console.WriteLine($"I have $"); // I have $100 account.Deposit(50f); Console.WriteLine($"I have $"); // I have $150 > >

Общие рекомендации

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

Дополнительные сведения о производных типах см. в статье Наследование (Руководство по программированию на C#).

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

В случае реализации методов расширения для какого-либо типа необходимо помнить о следующих фактах:

Метод расширения никогда не будет вызван, если он имеет ту же сигнатуру, что и метод, определенный в типе.
Методы расширения вводятся в область действия на уровне пространства имен. Например, при наличии нескольких статических классов, содержащих методы расширения в единственном пространстве имен с именем Extensions , все они будут введены в область действия директивой using Extensions; .

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

См. также

Руководство по программированию на C#
Parallel Programming Samples (Образцы параллельного программирования, включают множество примеров методов расширения)
Лямбда-выражения
Общие сведения о стандартных операторах запроса
Conversion Rules for Instance Parameters and their Impact (Правила преобразования для параметров экземпляра и их влияние)
Extension Methods Interoperability between Languages (Взаимодействие между языками с помощью методов расширения)
Extension Methods and Curried Delegates (Методы расширения и каррированные делегаты)
Extension method Binding and Error reporting

Совместная работа с нами на GitHub

Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.