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

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

Функции расширения (extension function) позволяют добавить функционал к уже определенным типам. При этом типы могут быть определены где-то в другом месте, например, в стандартной библиотеке.

Функция расширения определяется следующим образом:

fun тип.имя_функции(параметры) : возвращаемый_тип

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

Определим пару функций расширения к стандартным типам Int и String:

fun main() < val hello: String = "hello world" println(hello.wordCount('l')) // 3 println(hello.wordCount('o')) // 2 println(4.square()) // 16 println(6.square()) // 36 >fun String.wordCount(c: Char) : Int < var count = 0 for(n in this)< if(n == c) count++ >return count > fun Int.square(): Int

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

fun Int.square(): Int

Через this обращаемся к тому объекту, для которого будет вызывться функция. И затем вы можем вызвать ее следующим образом:

4.square() // 16

Для типа String определена функция wordCount, которая подсчитывает, сколько встречается определенный символ в строке.

Следует учитывать, что в функциях расширения мы можем обращаться к любым общедоступным свойствам и методам объекта, однако не можем обращаться к свойствам и методам с модификаторами private и protected .

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

Методы расширения (Руководство по программированию в 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, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.

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 — это очень, очень плохо.

Простейшее расширение для Google Chrome: content script

Меня, почему-то, очень воодушевляет возможность писать расширения для хрома. Это не значит, что я этим воодушевлением как-то пользуюсь, но тем не менее. Задачи я получаю через Chrome, в нем же их потом тестирую, в нем же читаю (не)довольные письма от заказчиков после коммита, и на каждой стадии хватает мелочей, которые можно улучшить.

А расширение — оно простое. Манифест + какой-нибудь js файл с логикой — и всё.

Самое простое расширение, которое я когда-либо делал для себя — content script. Это обычный JavaScript файл, который подгружается для страниц, которые требуется надругать. У него полный доступ к DOM, что можно очень эффектно эксплуатировать. С моём случае скрипт подгружался для баг трэкера, пробегался по содержимому баг репорта и подсвечивал потенциально проблемные места красным, затенял менее приоритетные, форматировал историю навигации, stack trace, и т. п.. Читать такие кейсы было намного проще, да и времени экономилась уйма.

Hello world мира контентных скриптов обычно состоит из двух файлов: manifest.json и, например, helloWorld.js.

manifest.json
JavaScript
«name» : «Hello world» ,
«description» : «Do you really need a description for that?» ,
«version» : «0.1» ,
«manifest_version» : 2 ,
«content_scripts» : [ < "matches" : [ "http://www.html5rocks.com/*" ] , "js" : [ "helloWorld.js" ]

Поля вполне понятны, кроме, возможно, версий. Их две — одна на экстеншн, одна для манифеста (всегда двойка). В секцию content_scripts я иногда добавлял «css».

helloWorld.js вообще эстетически прекрасен:

helloWorld.js
console . log ( «hello world» ) ;

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

Добавить расширение в хром тоже элементарно:

• открываем хром
• заходим на chrome://extensions
• убеждаемся, что чекбокс Developer mode включен
• жмем кнопку Load unpacked extension
• натравливаем диалог на папку с манифестом.

Всё. Хром настолько вежлив, что если в манифесте были какие-то ошибки (например, JSON ключи не в кавычках), то он выскажет недоумение сразу же.

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

В одной из стран-членов ООН есть портал onliner.by, который во время сеанса прокрастинации сильно выручает новостями о мире, технике и дорожно-транспортных происшествиях. Есть только одна проблема — любое упоминание Apple, android или продукции, которая с ними связана, открывает портал в филиал ада сразу за первым комментариям.

Особенно плохо то, что моя ранимая психика подвисает на этих комментариях, и пока я на каждый коммент мысленно не отвечу автору, в чем именно он неправ, нормально работать не получится.

Можно сделать экстеншн, который детектит в заголовке статьи ключевые слова, и в случае чего заменяет комменты на котиков, плейсхолдеры — на что угодно. За базу легко сойдет предыдущий hello world.

Итак, манифест. Тут всё гуд, только поменяем html5rocks на онлайнер: