Расширения (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 членам приёмника.
© 2015—2023 Open Source Community
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 — это очень, очень плохо.
Экстеншн что это такое в программировании
Регистрация: 10.09.2007
Прошу помощи у сообщества.
Update43
Пытаюсь добавить во вьюху поле на основе метода.
Делаю класс-экстенш вьюхи. Пишу там метод.
Делаю экстенш самой вьюхи — метод не виден. При попытке создать поле и указать метод руками ругается на отсутствие метода при компиляции.
Что я делаю не так?
Непонятно, то ли не учел какую-то мелочь, то ли этого действительно не сделать.
Регистрация: 22.07.2003
« Предыдущая тема | Следующая тема »
| Похожие темы | ||||
| Тема | Автор | Раздел | Ответов | Посл. сообщение |
| Sumit Potbhare: Retail Warehousing | Wrap up | Approach to D365 for Commerce with Adv WH Mgmt | Blog bot | DAX Blogs | 0 | 28.04.2021 13:12 |
| patrickmouwen: How to Unlock Many Hidden D365 Retail Features! | Blog bot | DAX Blogs | 0 | 13.05.2020 22:13 |
| patrickmouwen: D365 Retail APIs Part III: How to use the Retail APIs from Power Automate (Flow) and Logic App | Blog bot | DAX Blogs | 0 | 28.01.2020 02:15 |
| patrickmouwen: D365 Retail APIs Part II: How to know exactly what happens inside D365 Retail | Blog bot | DAX Blogs | 0 | 14.12.2019 01:17 |
| Опции просмотра |
| Линейный вид |
| Комбинированный вид |
| Древовидный вид |
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
Экстеншн что это такое в программировании
Расширение (экстеншн, extension) — способ организации JS и CSS кода в продуктах 1С-Битрикс: Управление Сайтом и Битрикс24.
Расположение расширений
В продукте:
bitrix/js// bitrix/modules/js// local/js//
Примечание: в директории bitrix расположены только те экстеншны, которые поставляются с продуктами 1С-Битрикс: Управление Сайтом и Битрикс24. Клиентские экстеншны должны располагаться в папке local.
Структура
- myextension
- src — исходные файлы
- dist — бандлы Бандл (bundle, комплект/набор) — это совокупность каких-либо программных данных (файлов), объеденных по какому-либо признаку. В данном случае бандлы — это обработанные и объединенные исходные файлы. для браузера
- bundle.config.js — конфигурационный файл для сборщика
- config.php — конфигурационный файл экстеншна
- lang — локализации
- test — тесты
- @types — файлы *.d.ts
Обязательные элементы: src, dist, bundle.config.js, config.php.
Необязательные элементы (директории): lang, test, @types.
Если у вас установлен @bitrix/cli , то структуру расширения можно создать Для создания расширения («экстеншна»):
1) Перейдите в директорию local/js/
2) Выполните команду bitrix create
3) Ответьте на вопросы мастера
Подробнее. , выполнив команду bitrix create .
src
В директории src следует располагать исходные файлы в формате ES6. Из файлов в данной директории на основании данных файла конфигурации и внутренних ссылок будут созданы финальные версии для подключения в браузере (бандлы) в формате ES5.
Внутри файла вы можете использовать import других файлов из текущей директории или импортировать другие CoreJS расширения.
Для импорта переменных и классов из другого файла в текущей директории используйте следующий синтаксис:
-
если в папке src есть файл file.js и в нем есть экспортируемый класс SomeClass:
import from "./file";
import './file.css';
import from 'main.loader';
import "main.date";
dist
В директории dist располагаются файлы, автоматически созданные с помощью сборщика для последующего подключения в браузере. Обычно это файлы .bundle.js и .bundle.css.
bundle.config.js
Файл конфигурации сборщика.
module.exports = < input: './src/app.js', output: './dist/app.bundle.js', >;
module.exports = < // Файл, для которого необходимо выполнить сборку. // Обычно это './src/.js // Необходимо указать относительный путь input: string, // Путь к бандлу, который будет создан в результате сборки // Обычно это ./dist/.bundle.js // Необходимо указать относительный путь output: string, // Неймспейс, в который будут добавлены все экспорты из файла указанного в input // Например 'BX.Main.Filter' namespace: string, // Списки файлов для принудительного объединения. // Файлы будут объединены без проверок на дублирование кода. // sourcemap's объединяются автоматически // Необходимо указать относительные пути concat: < js: Array, css: Array, >, // Разрешает или запрещает сборщику модифицировать config.php // По умолчанию true (разрешено) adjustConfigPhp: boolean, // Разрешает или запрещает сборщику удалять неиспользуемый код. // По умолчанию true (включено). treeshake: boolean, // Разрешает или запрещает пересобирать бандлы // если сборка запущена не в корне текущего экстеншна // По умолчанию `false` (разрешено) 'protected': boolean, plugins: < // Переопределяет параметры Babel. // Можно указать собственные параметры Babel // https://babeljs.io/docs/en/options // Если указать false, то код будет собран без транспиляции babel: boolean | Object, // Дополнительные плагины Rollup, // которые будут выполняться при сборке бандлов custom: Array, >, >;
config.php
Конфигурационный файл расширения определяет, какие файлы необходимо подключить на страницу.
При использовании @bitrix/cli файл config.php будет создан автоматически при сборке и будет обновляться автоматически по мере необходимости. Например, если в JS коде появится зависимость которая не указана в config.php, то она будет автоматически добавлена в rel.
if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) < die(); >return [ 'css' => './dist/loader.bundle.css', 'js' => './dist/loader.bundle.js', 'rel' => [ 'main.core' ] ];. return [ // Путь к `css` файлу или массив путей // Рекомендуется указывать относительный путь 'css' => String | Array, // Путь к `js` файлу или массив путей к `js` файлам // Рекомендуется указывать относительный путь 'js' => String | Array, // Список зависимостей // Необходимо указать имена расширений, которые должны быть // подключены перед подключением текущего расширения // Зависимости подключаются рекурсивно и с учетом указанного порядка 'rel' => String | Array, // Путь к файлу с языковыми фразами или массив путей // файл `lang//config.php` подключается автоматически, // его тут можно не указывать 'lang' => String | Array, // Запрещает подключать `main.core` автоматически, как зависимость // По умолчанию `false` — `main.core` подключается. // При сборке бандла значение параметра устанавливается автоматически // если в коде нет прямой зависимости на `main.core` 'skip_core' => Boolean, // Обработчик, который вызывается перед подключением расширения на страницу // в качестве первого параметра будет передан массив конфигурации расширения // обработчик может модифицировать этот массив и вернуть из функции // Это может быть полезно когда необходимо добавить в языковые фразы // какие-то данные с сервера 'oninit' => Function, // Дополнительные языковые фразы // Это может быть полезно для передачи вычисляемых значений языковых фраз // Принимает массив. В качестве ключей необходимо указывать идентификаторы языковых фраз 'lang_additional' => Array, // Параметр доступен с версии 20.5.100 модуля main. // Параметр позволяет указать настройки, // которые могут быть получены в JS, // с помощью метода Extension.getSettings(). 'settings' => Array ];
@types
Директория может содержать файлы .d.ts с описанием публичного JS API расширения, на TypeScript. Рекомендуется использовать *.d.ts файлы для описания API библиотек, написанных на ES5. Описывать ES6 код не нужно.
Пример описания расширения main.loader:
declare module 'main.loader' < type loaderOptions = < target?: HTMLElement, size?: number, mode?: 'absolute' | 'inline' | 'custom', offset?: < top?: string, left?: string >, color?: string >; class Loader < constructor(options?: loaderOptions); readonly layout: HTMLElement; readonly circle: HTMLElement; createLayout(): HTMLElement; show(target?: HTMLElement): Promise; hide(): Promise; isShown(): boolean; setOptions(options: loaderOptions): void; destroy(): void; > >
test
Директория должна содержать вложенные директории и файлы Mocha Mocha (Мока) — JavaScript тест-фреймворк, который можно запускать как на node.js, так и в браузере, удобен для асинхронного тестирования. Тесты Mocha запускаются серийно, позволяя гибко и точно создавать отчеты.
Подробнее. -тестов. Для каждого файла должна создаваться директория с именем тестируемого файла и вложенным в нее файлом с тестами в формате .test.js.
Например, при такой структуре в `src`
директория test должна иметь следующую структуру:
Использование расширений
\Bitrix\Main\UI\Extension::load('main.loader');-
Импорт экспортов расширения:
import from 'main.loader';
Если вы хотите импортировать старое расширение (не поддерживающие import ES6, например, main.date), укажите импорт без экспорта расширения:
import "main.date";
import from 'main.core'; loadExtension('main.loader').then(() => < // Код который использует `main.loader` >);