Что такое мост в приложениях

Что такое мост в приложениях

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

Даже если мы отделим абстракцию от конкретных реализаций, то у нас все равно все наследуемые классы будут жестко привязаны к интерфейсу, определяемому в базовом абстрактном классе. Для преодоления жестких связей и служит паттерн Мост.

Когда использовать данный паттерн?

• Когда надо избежать постоянной привязки абстракции к реализации
• Когда наряду с реализацией надо изменять и абстракцию независимо друг от друга. То есть изменения в абстракции не должно привести к изменениям в реализации

Общая реализация паттерна состоит в объявлении классов абстракций и классов реализаций в отдельных параллельных иерархиях классов.

Представление паттерна с помощью UML:

Связь агрегации между классами Abstraction и Implementor фактически и представляет некоторый мост между двумя параллельными иерархиями классов. Собственно поэтому паттерн получил название Мост.

Формальное описание паттерна на языке C#:

class Client < static void Main() < Abstraction abstraction; abstraction = new RefinedAbstraction(new ConcreteImplementorA()); abstraction.Operation(); abstraction.Implementor=new ConcreteImplementorB(); abstraction.Operation(); >> abstract class Abstraction < protected Implementor implementor; public Implementor Implementor < set < implementor = value; >> public Abstraction(Implementor imp) < implementor = imp; >public virtual void Operation() < implementor.OperationImp(); >> abstract class Implementor < public abstract void OperationImp(); >class RefinedAbstraction : Abstraction < public RefinedAbstraction(Implementor imp) : base(imp) <>public override void Operation() < >> class ConcreteImplementorA : Implementor < public override void OperationImp() < >> class ConcreteImplementorB : Implementor < public override void OperationImp() < >>

Участники

• Abstraction : определяет базовый интерфейс и хранит ссылку на объект Implementor. Выполнение операций в Abstraction делегируется методам объекта Implementor
• RefinedAbstraction : уточненная абстракция, наследуется от Abstraction и расширяет унаследованный интерфейс
• Implementor : определяет базовый интерфейс для конкретных реализаций. Как правило, Implementor определяет только примитивные операции. Более сложные операции, которые базируются на примитивных, определяются в Abstraction
• ConcreteImplementorA и ConcreteImplementorB : конкретные реализации, которые унаследованы от Implementor
• Client : использует объекты Abstraction

Теперь рассмотрим реальное применение. Существует множество программистов, но одни являются фрилансерами, кто-то работает в компании инженером, кто-то совмещает работу в компании и фриланс. Таким образом, вырисовывается иерархия различных классов программистов. Но эти программисты могут работать с различными языками и технологиями. И в зависимости от выбранного языка деятельность программиста будет отличаться. Для решения описания данной задачи в программе на C# используем паттерн Мост:

class Program < static void Main(string[] args) < // создаем нового программиста, он работает с с++ Programmer freelancer = new FreelanceProgrammer(new CPPLanguage()); freelancer.DoWork(); freelancer.EarnMoney(); // пришел новый заказ, но теперь нужен c# freelancer.Language = new CSharpLanguage(); freelancer.DoWork(); freelancer.EarnMoney(); Console.Read(); >> interface ILanguage < void Build(); void Execute(); >class CPPLanguage : ILanguage < public void Build() < Console.WriteLine("С помощью компилятора C++ компилируем программу в бинарный код"); >public void Execute() < Console.WriteLine("Запускаем исполняемый файл программы"); >> class CSharpLanguage : ILanguage < public void Build() < Console.WriteLine("С помощью компилятора Roslyn компилируем исходный код в файл exe"); >public void Execute() < Console.WriteLine("JIT компилирует программу бинарный код"); Console.WriteLine("CLR выполняет скомпилированный бинарный код"); >> abstract class Programmer < protected ILanguage language; public ILanguage Language < set < language = value; >> public Programmer (ILanguage lang) < language = lang; >public virtual void DoWork() < language.Build(); language.Execute(); >public abstract void EarnMoney(); > class FreelanceProgrammer : Programmer < public FreelanceProgrammer(ILanguage lang) : base(lang) < >public override void EarnMoney() < Console.WriteLine("Получаем оплату за выполненный заказ"); >> class CorporateProgrammer : Programmer < public CorporateProgrammer(ILanguage lang) : base(lang) < >public override void EarnMoney() < Console.WriteLine("Получаем в конце месяца зарплату"); >>

В роли Abstraction выступает класс Programmer, а в роли Implementor — интерфейс ILanguage, который представляет язык программирования. В методе DoWork() класса Programmer вызываются методы объекта ILanguage.

Языки CPPLanguage и CSharpLanguage определяют конкретные реализации, а классы FreelanceProgrammer и CorporateProgrammer представляют уточненные абстракции.

Таким образом, благодаря применению паттерна реализация отделяется от абстракции. Мы можем развивать независимо две параллельные иерархии. Устраняются зависимости между реализацией и абстракцией во время компиляции, и мы можем менять конкретную реализацию во время выполнения.

Что такое мост в приложениях

Мост – паттерн, оптимальным образом структурирующий используемые иерархии общих абстракций и их конкретных реализаций. Известен также под именем Handle/Body (описатель/тело).

Условия, Задача, Назначение

Главное назначение — отделить абстракцию от ее реализации так, чтобы то и другое можно было изменять независимо.
Полезность данного разделения появляется в случае, когда для некоторой абстракции возможно несколько реализаций. Обычно первым делом и в такой ситуации применяют наследование.
Абстрактный класс определяет интерфейс абстракции, а его конкретные подклассы по-разному реализуют его. Но такой подход не всегда обладает достаточной гибкостью. Наследование жестко привязывает реализацию к абстракции, что затрудняет независимую модификацию, расширение и повторное использование абстракции и ее реализации.

Мотивация

Рассмотрим реализацию переносимой (повторно используемой) абстракции окна в библиотеке для разработки пользовательских интерфейсов. Написанные с ее помощью приложения должны работать в разных средах, например под X Window System и Presentation Manager (PM) от компании IBM. С помощью наследования мы могли бы определить абстрактный класс Window и его подклассы XWindow и PMWindow, реализующие интерфейс окна для разных платформ. Но у такого решения есть два недостатка:

1. Неудобно распространять абстракцию Window на другие виды окон или новые платформы. Представьте себе абстрактный подкласс IconWindow, который специализирует (уточняет) абстракцию окна для пиктограмм. Чтобы поддержать пиктограммы на обеих платформах, нам придется реализовать два новых подкласса XlconWindow и PMIconWindow. И так далее по два подкласса необходимо будет также определять для каждого нового вида окон (DialogWindow) впоследствии. А для поддержки третьей платформы придется вообще для всех видов окон (Window, IconWindow, DialogWindow) определять по новому подклассу .

Клиентский код становится платформенно-зависимым. При создании окна клиент инстанцирует конкретный класс, имеющий вполне определенную реализацию. Например, создавая объект XWindow, мы привязываем абстракцию окна к ее реализации для системы X Window и, следовательно, делаем код клиента ориентированным именно на эту оконную систему. Таким образом, усложняется перенос клиента на другие платформы.
Клиенты должны иметь возможность создавать окно, не привязываясь к конкретной реализации. Только сама реализация окна должна зависеть от платформы, на которой работает приложение. Поэтому в клиентском коде не может быть никаких упоминаний о платформах.
Паттерн абстрактная фабрика конечно решил бы эту проблему, но от п.1 все равно не избавил бы, а наоборот усложнил бы проблему введения новых видов окон.

С помощью паттерна мост эти проблемы решаются. Абстракция окна и ее реализация помещаются в раздельные иерархии классов. Таким образом, существует одна иерархия для абстрактных классов окон (Window, IconWindow, TransientWindow) и другая (с корнем WindowImp) — для платформенно-зависимых конкретных реализаций. Так, подкласс XWindowImp предоставляет реализацию в системе X Window System.

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

Признаки применения, использования паттерна Мост (Bridge)

Используйте паттерн мост, когда:

1. Нужно избежать постоянной привязки абстракции к реализации.
2. Когда конкретную реализацию необходимо выбирать во время выполнения программы.
3. И абстракции, и реализации должны расширяться новыми подклассами. В таком случае паттерн мост позволяет комбинировать разные абстракции и реализации и изменять их независимо.
4. Изменения в реализации абстракции не должны сказываться на клиентах, то есть клиентский код не должен перекомпилироваться.
5. Количество классов начинает быстро расти, как мы видели на первой диаграмме из примера. Это признак того, что иерархию следует разделить на 2 части.
6. Вы хотите разделить одну и ту же реализацию между несколькими объектами, и этот факт необходимо скрыть от клиента.

Решение

Участники паттерна Мост (Bridge)

1. Abstraction (Window) – абстракция.
   Определяет интерфейс абстракции и агрегирует (хранит ссылку) на объект типа Implement.
2. RefinedAbstraction (IconWindow) — уточненная абстракция.
   Более специфичный подкласс основной абстракции, расширяет интерфейс, определенный абстракцией Abstraction.
3. Implementor (WindowImp) – исполнитель.
   Определяет интерфейс для классов реализации. Он не обязан точно соответствовать интерфейсу класса Abstraction, более того оба интерфейса могут быть совершенно различны. Обычно интерфейс класса Implementor предоставляет только примитивные операции, а класс Abstraction определяет операции более высокого уровня, базирующиеся на этих примитивах.
4. ConcreteImplementor (XWindowlmp, PMWindowlmp) – один из конкретных (платформо-зависимых) исполнителей.
   Содержит конкретную реализацию интерфейса класса Implementor, т.е. по-своему реализует примитивы, определенные в Implementor-е.

Схема использования паттерна Мост (Bridge)

Объект Abstraction решает свои задачи, реализует свою логику, пользуюсь методами объекта класса Implementor (примитивами), ссылку на которого он получает когда-то ранее, перед началом своей работы.

Вопросы, касающиеся реализации паттерна Мост (Bridge)

Если вы предполагаете применить паттерн мост, то подумайте еще о таких вопросах реализации:

1. Только один класс Implementor.
   В ситуациях, когда есть только одна реализация, создавать абстрактный класс Implementor необязательно. Это вырожденный случай паттерн мост – между классами Abstraction и Implementor существует взаимно-однозначное соответствие. Тем не менее разделение все же полезно, если нужно, чтобы изменение реализации класса не отражалось на существующих клиентах (должно быть достаточно заново скомпоновать программу, не перекомпилируя клиентский код).
   В C++ интерфейс класса Implementor можно определить в закрытом заголовочном файле, который не передается клиентам. Это позволяет полностью скрыть реализацию класса от клиентов.
2. Cоздание правильного объекта Implementor.
   Как, когда и где принимается решение о том, какой из нескольких классов Implementor инстанцировать?
   Если у класса Abstraction есть информация о конкретных классах Concretelmplementor, то он может инстанцировать один из них в своем конструкторе; какой именно — зависит от переданных конструктору параметров.
   Так, если класс коллекции поддерживает несколько реализаций, то решение можно принять в зависимости от размера коллекции. Для небольших коллекций применяется реализация в виде связанного списка, для больших – в виде хэшированных таблиц.
   Другой подход — заранее выбрать реализацию по умолчанию, а позже изменять ее в соответствии с тем, как она используется. Например, если число элементов в коллекции становится больше некоторой условной величины, то мы переключаемся с одной реализации на другую, более эффективную.
   Можно также делегировать решение другому объекту. В примере с иерархиями Window/WindowImp уместно было бы ввести фабричный объект (см. паттерн абстрактная фабрика), единственная задача которого — инкапсулировать платформенную специфику. Фабрика обладает информацией, объекты Windowlmp какого вида надо создавать для данной платформы, а объект Window просто обращается к ней с запросом о предоставлении какого-нибудь объекта Windowlmp, при этом понятно, что объект получит то, что нужно. Преимущество описанного подхода: класс Abstraction становится вообще уже напрямую не привязан ни к одному из классов Implementor – а, как мы знаем, чем меньше связанность сущностей, тем более система становится гибкой.
3. Некорректность использования множественного наследования
   В C++, например, для объединения интерфейса с его реализацией можно воспользоваться множественным наследованием. Например, класс может открыто наследовать классу Abstraction и закрыто – классу ConcreteImplementor. Но такое решение зависит от статического наследования и жестко привязывает реализацию к ее интерфейсу. Поэтому реализовать настоящий мост с помощью множественного наследования невозможно, по крайней мере в C++.

Результаты

Результаты применения паттерна мост:

1. Отделение реализации от интерфейса.
   Реализация больше не имеет постоянной привязки к интерфейсу. Реализацию абстракции можно конфигурировать во время выполнения. Объект может даже динамически изменять свою реализацию.
   Разделение классов Abstraction и Implementor устраняет также зависимости от реализации, устанавливаемые на этапе компиляции. Чтобы изменить класс реализации, теперь вовсе не обязательно перекомпилировать класс Abstraction и его клиентов. Это свойство особенно важно, если необходимо обеспечить двоичную совместимость между разными версиями библиотеки классов.
   Кроме того, такое разделение облегчает разбиение системы на слои и тем самым позволяет улучшить ее структуру. Высокоуровневые части системы должны знать только о классах Abstraction и Implementor.
2. Повышение степени расширяемости.
   Можно расширять независимо иерархии классов Abstraction и Implementor.
3. Сокрытие деталей реализации от клиентов.
   Клиенты, пользующиеся интерфейсом Abstraction, изолируются от деталей реализации этих операций, которые на самом деле выполняются с помощью вызовов методов Implementor-а. Что делает возможным прозрачную подмену Implementor-ов как статически на этапе компиляции, так и динамически.

Пример

Рассмотрим задачу построения общей системы команд. Существуют общие интерфейсы для выполнения тех или иных команд. При этом сами команды ничем не ограничиваются и могут выполнять любые задачи: редактирование файлов, работа с базой данных, отсылка e-mail и т.д. Соответственно, эту разнообразность команд необходимо абстрагировать, так чтобы клиенты, ничего не зная об их сущности, были способны запустить и обработать любую команду.

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

В качестве Abstraction выступает самый общий класс Command: Command.

Он агрегирует, хранит ссылку класс реализации команды CommandImpl (Implementor): CommandImpl.

Далее уточняем разновидности команд (RefinedAbstraction), как-то команды на удаление, добавление, редактирование. Например, можно выделить команды на редактирование и удаление: UpdateCommand, AddCommand.

Как видно, они для своих целей тоже пользуются интерфейсом Implementor-а CommandImpl.

Таким образом, получаем общие интерфейсы, с которыми будут работать клиенты: выполнять команды и анализировать ошибки в случае неудачи.

Теперь пора перейти к реализации конкретных алгоритмов обработки данных видов команд. Для реализации этих 2-х команд в файловом контексте, т.е. по отношению к файлам, будет достаточно определить следующие ConcreteImplementator-ы: FileCommand, UpdateFileCommand, AddFileCommand.

Соответственно для редактирования файла, объект класса UpdateCommand (или Command) нужно будет сконфигурировать настроенным объектом UpdateFileCommand, а для добавления файла – объектом AddFileCommand.

Для работы с базой данной ConcreteImplementator- ы примут вид: SQLCommand, SQLUpdateCommand.

Заметьте, что не приводится специальная реализация для команды добавления – в данном случае можно использовать ту же SQLUpdateCommand, т.к. все необходимые процедуры она выполняет (по крайней мере, они не отличаются от случая добавления – разница будет лишь в тексте SQL-запроса). И в этом еще одна гибкость паттерна мост – в большинстве случаев нам не приходится выстраивать полные строго параллельные иерархии реализаций для всех абстракций, т.к. часто одни и те же ConcreteImplementor-ы удовлетворяют нескольким RefinedAbstraction-нам.

Все, — теперь клиенты нашей системы могут свободно запускать данные команды добавления и редактирования в контекстах файлов или базы данных: Client.

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

Конкретные реализации clientUpdateImpl и balanceCorrectImpl для простоты здесь определяются напрямую, но как говорилось выше часто бывает полезно получать их динамически в конструкторе команды (Command) из абстрактной фабрики.

Известные применения паттерна Мост (Bridge)

Пример класса Window позаимствован из ЕТ++. В ЕТ++ класс WindowImp называется WindowPort и имеет такие подклассы, как XWindowPort и SunWindowPort. Объект Window создает соответствующего себе реализатора Implementor, запрашивая его у абстрактной фабрики, которая называется WindowSystem. Эта фабрика предоставляет интерфейс для создания платформенно-зависимых объектов: шрифтов, курсоров, растровых изображений и т.д.

Дизайн классов Window/WindowPort в ЕТ++ обобщает паттерн мост в том отношении, что WindowPort сохраняет также обратную ссылку на Window. Класс-реализатор WindowPort использует эту ссылку для извещения Window о событиях, специфичных для WindowPort: поступлений событий ввода, изменениях размера окна и т.д.

В работах Джеймса Коплиена и Бьерна Страуструпа упоминаются классы описателей и приводятся некоторые примеры. Основной акцент в этих примерах сделан на вопросах управления памятью, например разделении представления строк и поддержке объектов переменного размера. Нас же в первую очередь интересует поддержка независимых расширений абстракции и ее реализации.

В библиотеке libg++ определены классы, которые реализуют универсальные структуры данных: Set (множество), LinkedSet (множество как связанный список), HashSet (множество какхэш-таблица), LihkedList (связанный список) и HashTable (хэш-таблица). Set — это абстрактный класс, определяющий абстракцию множества, a LinkedList и HashTable — конкретные реализации связанного списка и хэш-таблицы. LinkedSet и HashSet — реализаторы абстракции Set, перекидывающие мост между Set и LinkedList и HashTable соответственно. Перед вами пример вырожденного моста, поскольку абстрактного класса Implement or здесь нет.

В библиотеке NeXT AppKit паттерн мост используется при реализации и отображении графических изображений. Рисунок может быть представлен по-разному. Оптимальный способ его отображения на экране зависит от свойств дисплея и прежде всего от числа цветов и разрешения. Если бы не AppKit, то для каждого приложения разработчикам пришлось бы самостоятельно выяснять, какой реализацией пользоваться в конкретных условиях.

AppKit предоставляет мост [google=NXImage NXImageRep]NXImage/NXImageRep[google]. Класс NXImage определяет интерфейс для обработки изображений. Реализация же определена в отдельной иерархии классов NXImageRep, в которой есть такие подклассы, как NXEPSImageRep, NXCachedlmageRep и NXBitMapImageRep. В классе NXImage хранятся ссылки на один или более объектов NXImageRep. Если имеется более одной реализации изображения, то NXImage выбирает самую подходящую для данного дисплея. При необходимости NXImage также может преобразовать изображение из одного формата в другой. Интересная особенность этого варианта моста в том, что NXImage может одновременно хранить несколько реализаций NXImageRep.

Родственные паттерны

Паттерн абстрактная фабрика может создать и сконфигурировать мост.
Для обеспечения совместной работы не связанных между собой классов прежде всего предназначен паттерн адаптер. Обычно он применяется в уже готовых системах. Мост же участвует в проекте с самого начала и призван поддержать возможность независимого изменения абстракций и их реализаций.

Что такое мост в приложениях

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

Даже если мы отделим абстракцию от конкретных реализаций, то у нас все равно все наследуемые классы будут жестко привязаны к интерфейсу, определяемому в базовом абстрактном классе. Для преодоления жестких связей и служит паттерн Мост.

Когда использовать данный паттерн?

Когда надо избежать постоянной привязки абстракции к реализации

Когда наряду с реализацией надо изменять и абстракцию независимо друг от друга. То есть изменения в абстракции не должно привести к изменениям в реализации

Общая реализация паттерна состоит в объявлении классов абстракций и классов реализаций в отдельных параллельных иерархиях классов.

Представление паттерна с помощью UML:

Связь агрегации между классами Abstraction и Implementor фактически и представляет некоторый мост между двумя параллельными иерархиями классов. Собственно поэтому паттерн получил название Мост.

Формальное описание паттерна на языке C#:

Участники

Abstraction : определяет базовый интерфейс и хранит ссылку на объект Implementor. Выполнение операций в Abstraction делегируется методам объекта Implementor

RefinedAbstraction : уточненная абстракция, наследуется от Abstraction и расширяет унаследованный интерфейс

Implementor : определяет базовый интерфейс для конкретных реализаций. Как правило, Implementor определяет только примитивные операции. Более сложные операции, которые базируются на примитивных, определяются в Abstraction

ConcreteImplementorA и ConcreteImplementorB : конкретные реализации, которые унаследованы от Implementor

Client : использует объекты Abstraction

Теперь рассмотрим реальное применение. Существует множество программистов, но одни являются фрилансерами, кто-то работает в компании инженером, кто-то совмещает работу в компании и фриланс. Таким образом, вырисовывается иерархия различных классов программистов. Но эти программисты могут работать с различными языками и технологиями. И в зависимости от выбранного языка деятельность программиста будет отличаться. Для решения описания данной задачи в программе на C# используем паттерн Мост:

В роли Abstraction выступает класс Programmer, а в роли Implementor — интерфейс ILanguage, который представляет язык программирования. В методе DoWork() класса Programmer вызываются методы объекта ILanguage.

Языки CPPLanguage и CSharpLanguage определяют конкретные реализации, а классы FreelanceProgrammer и CorporateProgrammer представляют уточненные абстракции.

Таким образом, благодаря применению паттерна реализация отделяется от абстракции. Мы можем развивать независимо две параллельные иерархии. Устраняются зависимости между реализацией и абстракцией во время компиляции, и мы можем менять конкретную реализацию во время выполнения.

Что такое блокчейн мосты

Сами по себе блокчейн-сети абсолютно никак не могут обмениваться информацией и взаимодействовать друг с другом. Такая ситуация приводит к замедлению развития всей крипто-сферы.

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

Например, какое-нибудь децентрализованное приложение (dApp) работает в сети ERC20, данное приложение будет взаимодействовать с пользователями и использовать смарт-контракты только внутри одной сети. Для того чтобы приложение также взаимодействовало в другой блокчейн-сети, его необходимо воссоздать почти с нуля в новом пространстве.

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

Именно для решения данной проблемы существуют мосты между блокчейнами.

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

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

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

Блокчейн-мост — это соединение, которое позволяет передавать токены или произвольные данные из одной цепочки в другую. Обе цепочки могут иметь различные протоколы, правила и модели управления, но мост обеспечивает совместимый способ безопасного взаимодействия с обеих сторон.

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

Для перевода токена из одной сети в другую с помощью моста, используется «обернутый токен» (Wrapped Token).

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

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

Используя мосты, мы можем «обернуть» BTC, получить WBTC и использовать его в сети Ethereum. Аналогично, мы можем совершить обратную операцию и перевести WBTC в BTC.

Существует множество различных конструкций мостов, но их обычно можно разделить на два типа: более централизованные и более децентрализованные:

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

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

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

Предположим, вы хотите переместить токены из цепочки A в цепочку B. Что делают мосты — они временно блокируют или замораживают ваш актив в цепочке A. Затем создается эквивалентное количество новых токенов, которые будут разблокированы для вас в цепочке B. Когда вы хотите выкупить токены, то есть когда вы хотите переместить исходные активы обратно из цепочки B в исходную цепочку (цепочку A), токены, созданные в цепочке B, будут сожжены, а исходные активы будут разблокированы.

Активы в блокчейне A будут разблокированы только тогда, когда эквивалентное количество созданных токенов в блокчейне B будет сожжено или снова заблокировано. Это не позволяет пользователям одновременно использовать активы в обоих блокчейнах.

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

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

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

Мост на C#

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

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

Сложность:

Популярность:

Применимость: Паттерн Мост особенно полезен когда вам приходится делать кросс-платформенные приложения, поддерживать несколько типов баз данных или работать с разными поставщиками похожего API (например, cloud-сервисы, социальные сети и т. д.)

Признаки применения паттерна: Если в программе чётко выделены классы «управления» и несколько видов классов «платформ», причём управляющие объекты делегируют выполнение платформам, то можно сказать, что у вас используется Мост.

Концептуальный пример

Этот пример показывает структуру паттерна Мост, а именно — из каких классов он состоит, какие роли эти классы выполняют и как они взаимодействуют друг с другом.

Program.cs: Пример структуры паттерна

Output.txt: Результат выполнения

Мост на других языках программирования

Купи книгу Погружение в Паттерны и получи архив с десятками детальных примеров, которые можно открывать прямо в IDE.

Как применяется мост при проектировании приложений?

Мост (bridge) — это паттерн проектирования, который позволяет разделить абстракцию от её реализации. Он построен на основе композиции, то есть объединения нескольких классов для создания более сложного класса.

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

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

Похожие публикации:

1. Если банк одобрил ипотеку что делать дальше
2. Как поменять пароль в метамаске на компьютер
3. Пропаганда что с ними стало
4. Чем отличается золотая карта сбербанка от серебряной

Что такое мосты и для чего они нужны?

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

Зачем мне это?
Если у вас в какой-то из сетей средства лежат “без дела” или увидели более “вкусные” проценты в DEX или протоколах кредитования на другой сети и не хотите использовать централизованные биржи (CEX) для переноса и конвертации — вам прямая дорога к ним.
Ниже мы рассмотрим мосты, которые поддерживают NEAR Protocol и EVM Aurora.

Доступные мосты

№ п/п	Сеть	NEAR Protocol	Aurora	Токены
1	Rainbow Bridge	+	+	ETH, AAVE, AURORA, BAL, BAT, BRRR, CGT, COMP, CREAM, DAI, DODO, FLX, FRAX, FXS, HAPI, LINEAR, LINK, MKR, MODA, OCT, OIN, PAD, PICKLE, REF, REN, SNX, STNEAR, SUSHI, UNI, USDC, USDT, WBTC, WNEAR, WOO, YFI
2	Allbridge	+	+	ABR, BUSD(BNB Chain), atUSTC(Celo,Fuse,Solana), abBUSD (Solana), atLUNC (Solana), CELO(Celo,Solana), SOL(Celo,Polygon,Solana,Fantom), cUSD (Celo), NEAR(Polygon,Solana), acUSD (Solana) LUNC (Terra), USTC (Terra)
3	Rubic	+	Работает как DEX, позволяет обменять имеющиеся токены на необходимые
4	Multichain	+	BUSD, FRAX
5	BoringDAO	+	USDT, USDC, ETH
6	Celer cBridge	+	FXS, FRAX, USDT, USDC, BUSD
7	Synapse	+	USDC, USDT, nUSD, SYN
8	Bungee	+	Агрегатор кроссчейн решений, позволяет обменять имеющиеся токены на необходимые
9	Meson	+	USDT, USDC
10	Swidge	+	Работает как DEX, позволяет обменять имеющиеся токены на необходимые
11	EYWA	+	eUSD
12	Portal	+	+
13	Router Protocol	+	USDC, ROUTE, DFYN, ETH
14	Tonana	+	+	ETH, NEAR, AURORA, ATOM, SOL, TON
15	Via Protocol	+	Широкий выбор доступных токенов, работает с DEXами
16	XP Network	+	NFT
17	Swing	+	Широкий выбор токенов, для сети Aurora доступны USDC, USDTSYN, ESW, UST, nUSD
18	ChainPort	+
19	Octopus Bridge	+	Позволяет взаимодействовать с эпчейнами Octopus Network

1. Rainbow Bridge
Самый простой и доступный мост. Имеет удобный пользовательский интерфейс и позволяет переводить средства между сетями NEAR Protocol, Aurora и Ethereum. Выбрать сети можно на первом шаге и произвести подключение к вашим кошелькам. Позволяет работать с кошельком MetaMask для сетей Ethereum и Aurora, а для подключения к NEAR Protocol предлагается выбрать нативный кошелёк или MyNearWallet.

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

При переносе токенов между сетями NEAR Protocol и Aurora взимается плата равная цене транзакции в сети NEAR Protocol.
Что хочется отметить – отсутствие минимального количества для переноса.
И для любителей темной темы – она тоже присутствует! 

2. Allbridge

Мост позволяет работать с сетями Aurora, Avalanche, BNB Chain, Celo, Ethereum, Fantom Opera, Fuse, Harmony, HECO Chain, Near, Polygon (Matic), Solana, Terra, XRP Ledger.
После нажатия “Connect wallet” выбираем способ подключения.

Доступные для переноса токены будут видны в верхнем списке при выборе актива.

С комиссиями при работе моста можно ознакомиться здесь
Меню на английском языке.
К сожалению, для пользователя сетей Aurora и NEAR выбор токенов для переноса невелик.
Из стейблконинов можно перенести BUSD из BNB Chain, правда получим abBUSD, но его можно обменять на необходимый на Rose.fi

3. Rubic

Rubic – мультичейн протокол, позволяющий пользователям совершать обмен токенов из таких сетей, как: Ethereum, Binance Smart Chain (BSC), Polygon (Matic), Bitcoin (добавляется), Tron, Avalanche, Fantom, Kava, Optimism, Arbitrum, Bitgert, Eth PoW, Aurora, Moonbeam, Fuse, Moonriver, Telos EVM, Celo, OKXChain, Cronos, Gnosis, Boba, Harmony.
Для подключения доступны следующие кошельки:

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

В целом простой и удобный мост, позволяет переводить стейблкоины (USDT, USDC и др), есть русская локализация.

4. Multichain

Multichain позволяет работать с сетями Ethereum, Arbitrum Nova, Arbitrum, Avalanche, BNB Chain, Bitgert, CLV Parachain, Celo, Conflux eSpace, Cronos, Dogechain, Dynochain, ETHW, Ethereum Classic, Evmos, Fantom, Fuse, Fusion, Godwoken, HECO, KCC, KardiaChain, Kava, Kekchain, Milkomeda (Algorand), Milkomeda (Cardano), MintMe.com Coin, Moonbeam, Moonriver, OKC, Oasis, Optimism, Polygon (Matic), Public Mint, Rei, Rangers, Rootstock, Shiden Network, Step Network, Syscoin, Telos, TomoChain, Velas, WEMIX3.0, sBCH.

Для подключения доступны следующие кошельки:

Для работы с NEAR Protocol вам необходимо установить расширение Sender Wallet.

Есть светлая и темная тема. Меню на английском языке.
Из стейблов на Aurora можно перенести BUSD и FRAX. Есть минимумы для переводов.
Примечательно, что конечная сеть (ее наличие в списке доступных), зависит от выбранного для переноса актива.

Бридж поддерживает работу с сетями: Ethereum, OKC, BNB, Polygon, Avalanche, Heco, Fantom, Gnosis, Metis, Arbitrum, Optimism, Aurora, KCC, IoTeX, Boba.

Для подключения доступны следующие кошельки:

Для перевода в разделе “BridgeAggregator” необходимо выбрать токен и сети, откуда и куда необходимо перевести средства.

Сразу можно увидеть количество, которое получим в заданной сети и комиссию.

Если вы привыкли к oPortal — выберите раздел v2-oportal.

В Aurora доступны для переноса следующие активы: USDT, USDC, ETH.

6. Celer cBridge
В целом довольно неплохой и интуитивно понятный мост, простой в работе, имеет светлую и темную тему. Русского языка не нашел, но и без него все понятно.
Для подключения доступны:

Подключаем свой кошелёк Metamask

Работает с сетями: Ethereum, Astar, BNB Chain, Avalanche, Polygon (Matic), Arbitrum, Optimism, Aptos, Fantom, Flow Mainnet, Metis Mainnet, Oasis, Evmos, Aurora, Moonbeam, Moonriver, Boba, OKXChain, Heco, Celo, Ape, Clover, Conflux, Crab Smart Chain, Gnosis Chain, Kava EVM Co-Chain, Klaytn, Milkomeda A1 (Algorand), Milkomeda C1 (Cardano), Nervos Godwoken, Ontology EVM, PlatON, REI Network, SX Network, Shiden, Swimmer Network.

Позволяет переносить USDT, USDC. Доступные для переноса токены зависят от выбраной сети.

7. Synapse

Для подключения можно использовать:

Простое и понятное кроссчейн-решение. Позволяет в исходной сети указать доступный стейблкоин, а в сети AURORA получить USDT или USDC.

Работает с сетями Ethereum, Avalanche, Arbitrum, BNB Chain, Optimism, Polygon (Matic), Aurora, Boba Network, Cronos, DFK Chain, Dogechain, Fantom, Harmony, Metis, Klaytn, Moonbeam, Moonriver, Terra.

8. Bungee

Скрин говорит сам за себя.
Bungee — это агрегатор мостов. Приложение, созданное командой Socket, которое поможет переместить ваши активы между сетями, используя оптимальный маршрут.

Для подключения нам доступно:

Из особенностей хочется выделить возможность получения газа для транзакций, с помощью функции Refuel (в Ethereum недоступна)

Работает с сетями: Ethereum, Avalanche, Arbitrum, Aurora, BSC, Fantom, Gnosis, Polygon (Matic), Optimism.
Подробней о работе Bungee и планах команды можно узнать из прошедшей АМА-сессии.

9. Meson

Мост Meson имеет простой и доступный интерфейс. Выполнен в светлых тонах, глаз не режет. Есть русская локализация.
Работает с сетями Ethereum, BNB Chain, Polygon (Matic), Arbitrum, Optimism, Avalanche, Tron, Fantom, Aurora, Conflux eSpace, Moonriver, Cronos, Aptos
Подключиться можно с помощью:

Позволяет перенести такие стейблкоины, как USDT, USDC.

10. Swidge

Swidge — решение, которое поможет обменять ваши активы из одной сети, на активы в другой сети.

Подключаем кошелёк

Работает с сетями: Ethereum, Aurora, Polygon (Matic), Binance Smart Chain (BSC), Gnosis, Fantom, OKXChain, Avalanche, Arbitrum, Optimism, Moonriver, Moonbeam, Celo, FUSE, Cronos, Velas, Boba, Heco, Harmony, Evmos.

Совершает обмен токенов, которые торгуются на интегрированных DEX-ах.

1. EYWA

Работает с сетями: Ethereum, Aurora, Arbitrum, Avalanche, BNB Chain, Fantom, Polygon (Matic)
При переводе доступных токенов из других сетей, в сети Aurora вы получите eUSD. В обратном порядке eUSD можно обменять также на любой доступный токен

1. Portal

Для совершения перевода из сети NEAR Protocol нужно будет подключиться одним из следующих кошельков:

Но есть одно НО, для взаимодействия с кошельком необходимо предоставить бриджу ПОЛНЫЙ доступ к вашему кошельку. Одним словом DYOR…

И предупреждают нас об этом целых два раза!

Взаимодействие с EVM-сетями возможно через Wallet Connect. Работа с Aurora пока приостановлена.

1. Router Protocol

Подключение

Работает с сетями: Aurora, BSC, Avalanche, Arbitrum, Fantom, Optimism, Ethereum, Kava.
Позволяет переносить активы между сетями c использованием стейблкоинов для оценки стоимости трансфера
Если среди доступных токенов нет необходимого, то можно добавить его по адресу

1. Tonana

Работает с сетями: Ethereum, Aurora, NEAR, Solana, Ton, Cosmos

1. Via Protocol

Работает с сетями Polygon (Matic), Arbitrum, Optimism, Ethereum, BSC, Avalanche, Fantom, Gnosis, Solana, Moonbeam, Aurora, Moonriver, Harmony, Boba, Cronos, Osmosis, Celo, Cosmos, Astar, Fuse, Bitcoin, Litecoin, Bitcoin Cash, KCC, Cube, Tron

Есть возможность передачи газ для последующих комиссий в другой сети.

При создании перевода подбирает оптимальный маршрут

1. XP Network

Мультичейн NFT мост.
Доступна работа со следующими кошельками:

Работает с сетями: Godwoken, VeChain, Harmony, Aurora, Ethereum, Polygon, BSC, Avalanche, Tron, Algorand, Tezos, Elrond, Fanton, Gnosis, GateChain, Iotex, Velas, Fuse

Swing — это децентрализованный межсетевой криптопротокол, который агрегирует ликвидность от децентрализованных бирж (DEX) и связывает блокчейны, позволяет пользователям перемещать криптоактивы из одной цепочки блоков в другую и выполнять межсетевые сделки и свопы децентрализованным способом.

Подключаем кошелёк

Работает со следующими сетями: Arbitrum, Aurora, Avalanche, Axelar, BSC, BitTorrent, Boba, Cosmohub, Crescent, Cronos, DeFi Kingdoms, Ethereum, Fantom, Fetch, Fuse, Gather, Gnosis, Harmony, Heco, Injective, Juno, Kujira, Metis, Moonbeam, Moonriver, OK Ex Chain, Oasis Emerald, Optimism, Osmosis, Polygon, Secret, Sei, Solana, Terra, e-Money
В сеть Aurorra можно перенести стейблкоины.

1. ChainPort

Подключаемся с помощью следующих кошельков:

Работает с сетями Ethereum, BSC, Polygon, Avalanche, Fantom, Fuse, Moonriver, Aurora, Dogechain, Cardano

1. Octopus Bridge
   Данный мост позволяет передавать токены из сети NEAR Protocol в сеть эпчейнов Octopus Network.