Слабая связь - Loose coupling

В вычисление и проектирование систем а слабо связанный система - это та, в которой каждый из компоненты имеет или использует мало или совсем не знает определения других отдельных компонентов. Подрайоны включают связь классов, интерфейсов, данных и сервисов.^[1] Слабая связь противоположна сильной связи.

Преимущества и недостатки

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

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

В интеграции

Слабая связь в более широком смысле распределенная система дизайн достигается за счет использования транзакций, очередей, предоставляемых промежуточное ПО, ориентированное на сообщения и стандарты взаимодействия.^[2]

Четыре типа автономии, которые способствуют слабой связи: справочная автономия, автономия времени, автономность формата, и автономность платформы.^[3]

Слабое соединение - это архитектурный принцип и цель дизайна в сервис-ориентированные архитектуры; одиннадцать форм слабой связи и их аналоги с сильной связью перечислены в:^[4]

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

Корпоративная служебная шина (ESB) промежуточное ПО было изобретено для достижения слабой связи в нескольких измерениях;^[5] однако чрезмерно спроектированные и неправильно расположенные ESB также могут иметь обратный эффект и создавать нежелательные тесные связи и центральную архитектурную точку доступа.

Архитектура, управляемая событиями также направлен на содействие слабой связи.^[6]

Способы уменьшения сцепления

Слабое связывание интерфейсов можно улучшить, опубликовав данные в стандартном формате (например, XML или JSON ).

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

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

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

В программировании

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

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

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

Пример свободного соединения.JPG

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

Пример сильной связи.JPG

Другие формы

Языки компьютерного программирования, имеющие представление о любой из функций в качестве основного модуля (см. Функциональное программирование ) или функции как объекты - отличные примеры слабосвязанного программирования. Функциональные языки имеют шаблоны Продолжение, Закрытие, или генераторы. Увидеть Clojure и Лисп как примеры языков программирования функций. Объектно-ориентированные языки, такие как Болтовня и Рубин есть блоки кода, тогда как Эйфель есть агенты. Основная идея состоит в том, чтобы объективировать (инкапсулировать как объект) функцию, независимую от какой-либо другой охватывающей концепции (например, отделить объектную функцию от любого прямого знания окружающего объекта). Увидеть Первоклассная функция для дальнейшего понимания функций как объектов, что квалифицируется как одна из форм первоклассной функции.

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

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

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

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

Связь элементов данных измерения

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

Добавление новых элементов данных в сообщения
Изменение порядка элементов данных
Изменение названий элементов данных
Изменение структуры элементов данных
Пропуск элементов данных

Смотрите также

использованная литература

^ Слабо связанные: недостающие части веб-сервисов от Дуг Кэй
^ Паутассо К., Уайлд Э., Почему Интернет слабосвязанный?, Proc. WWW 2009
^ Ф. Лейманн Слабое соединение и архитектурные последствия В архиве 2016-10-02 в Wayback Machine, Основной доклад ESOCC 2016
^ Н. Йосуттис, SOA на практике. О'Рейли, 2007 год, ISBN 978-0-596-52955-0.
^ М. Кин и др., Шаблоны: реализация SOA с использованием служебной шины предприятия, IBM, 2004 г.
^ Как EDA расширяет SOA и почему это важно Джек Ван Хоф

[1] Слабо связанные: недостающие части веб-сервисов от Дуг Кэй

[2] Паутассо К., Уайлд Э., Почему Интернет слабосвязанный?, Proc. WWW 2009

[3] Ф. Лейманн Слабое соединение и архитектурные последствия В архиве 2016-10-02 в Wayback Machine, Основной доклад ESOCC 2016

[4] Н. Йосуттис, SOA на практике. О'Рейли, 2007 год, ISBN 978-0-596-52955-0.

[5] М. Кин и др., Шаблоны: реализация SOA с использованием служебной шины предприятия, IBM, 2004 г.

[6] Как EDA расширяет SOA и почему это важно Джек Ван Хоф

[1]

[2]

[3]

[4]

[5]

[6]