В вычислительной технике и проектировании систем слабосвязанная система — это одна из
Компоненты в слабосвязанной системе можно заменить альтернативными реализациями, предоставляющими те же услуги. Компоненты в слабосвязанной системе менее привязаны к одной и той же платформе, языку , операционной системе или среде сборки.
Если системы разделены во времени, трудно обеспечить целостность транзакций; требуются дополнительные протоколы координации. Репликация данных между разными системами обеспечивает слабую связь (в доступности), но создает проблемы с поддержанием согласованности ( синхронизация данных ).
Слабая связь в более широком проекте распределенной системы достигается за счет использования транзакций, очередей, обеспечиваемых промежуточным программным обеспечением, ориентированным на сообщения , и стандартов совместимости. [2]
Четыре типа автономии, которые способствуют слабой связи: автономия ссылок , автономия времени , автономия формата и автономия платформы . [3]
Слабая связь — это архитектурный принцип и цель проектирования сервис-ориентированных архитектур . Одиннадцать форм слабой связи и их аналоги с сильной связью перечислены в: [4]
Промежуточное программное обеспечение Enterprise Service Bus (ESB) было изобретено для достижения слабой связи во многих измерениях. [5] Однако перепроектированные и неправильно расположенные ESB также могут иметь противоположный эффект и создавать нежелательную тесную связь и центральную архитектурную горячую точку.
Архитектура, управляемая событиями, также направлена на обеспечение слабой связи. [6]
Слабую связь интерфейсов можно улучшить, публикуя данные в стандартном формате (например, XML или JSON ).
Слабую связь между программными компонентами можно улучшить, используя в параметрах стандартные типы данных. Для передачи настраиваемых типов данных или объектов требуется, чтобы оба компонента знали определение настраиваемых данных.
Слабую связь между сервисами можно улучшить, сократив информацию, передаваемую в сервис, до ключевых данных. Например, сервис, отправляющий письмо, наиболее пригоден для повторного использования, когда передается только идентификатор клиента и получается адрес клиента внутри сервиса. Это отделяет службы, поскольку службы не нужно вызывать в определенном порядке (например, GetCustomerAddress, SendLetter).
Связь относится к степени прямого знания одного компонента о другом. Слабая связь в вычислениях интерпретируется как инкапсуляция в сравнении с неинкапсуляцией.
Примером жесткой связи является ситуация, когда зависимый класс содержит указатель непосредственно на конкретный класс, обеспечивающий требуемое поведение. Зависимость не может быть заменена или ее «сигнатура» изменена без внесения изменений в зависимый класс. Слабая связь возникает, когда зависимый класс содержит указатель только на интерфейс, который затем может быть реализован одним или несколькими конкретными классами. Это известно как инверсия зависимостей . Зависимость зависимого класса связана с «контрактом», указанным в интерфейсе; определенный список методов и/или свойств, которые должны предоставлять реализующие классы. Таким образом, любой класс, реализующий интерфейс, может удовлетворить зависимость зависимого класса без необходимости изменения класса. Это обеспечивает расширяемость разработки программного обеспечения. Новый класс, реализующий интерфейс, может быть написан для замены текущей зависимости в некоторых или всех ситуациях, не требуя изменения зависимого класса; новые и старые классы можно свободно менять местами. Сильная связь не позволяет этого сделать.
Это UML- диаграмма, иллюстрирующая пример слабой связи между зависимым классом и набором конкретных классов, обеспечивающих требуемое поведение:
Для сравнения на этой диаграмме показан альтернативный вариант с сильной связью между зависимым классом и поставщиком:
Языки компьютерного программирования, в которых понятия либо о функциях как о базовом модуле (см. Функциональное программирование ), либо о функциях как об объектах, представляют собой превосходные примеры слабосвязанного программирования. В функциональных языках есть шаблоны продолжений , замыканий или генераторов. См. Clojure и Lisp как примеры функциональных языков программирования. Объектно-ориентированные языки, такие как Smalltalk и Ruby, имеют блоки кода, а Eiffel — агенты. Основная идея состоит в том, чтобы объективировать (инкапсулировать в объект) функцию, независимую от любого другого включающего понятия (например, отделить объектную функцию от любого прямого знания включающего объекта). См. «Функция первого класса» для получения более подробной информации о функциях как объектах, что квалифицируется как одна из форм функции первого класса.
Например, в объектно-ориентированном языке, когда на функцию объекта ссылаются как на объект (освобождая его от каких-либо знаний о включающем его хост-объекте), новый объект функции может быть передан, сохранен и вызван позже. . Объекты-получатели (которым передаются эти функциональные объекты) могут безопасно выполнять (вызывать) содержащуюся функцию по своему усмотрению без какого-либо прямого знания включающего хост-объекта. Таким образом, программа может выполнять цепочки или группы функциональных объектов, при этом безопасно отделяясь от каких-либо прямых ссылок на включающий хост-объект.
Телефонные номера являются отличным аналогом и могут легко проиллюстрировать степень этого разделения.
Например, одна организация предоставляет другой номер телефона для выполнения определенной работы. Когда набирают этот номер, вызывающая сущность фактически говорит: «Пожалуйста, сделайте для меня эту работу». Развязка или слабая связь сразу бросаются в глаза. Субъект, получающий номер, может не знать, откуда взялся этот номер (например, ссылка на поставщика номера). С другой стороны, вызывающий абонент отделен от конкретных знаний о том, кому он звонит, где он находится, а также от знания того, как внутри страны действует получатель вызова.
Развивая пример еще дальше, абонент может сказать получателю звонка: «Пожалуйста, сделайте для меня эту работу. Перезвоните мне по этому номеру, когда закончите». «Номер», предлагаемый получателю, называется «обратным вызовом». Опять же, очевидна слабая связанность или несвязанность этого функционального объекта. Получатель обратного вызова не знает, что или кому звонят. Он знает только, что может позвонить, и сам решает, когда позвонить. На самом деле обратный звонок может быть адресован даже не тому, кто его изначально осуществил. Именно этот уровень косвенности делает функциональные объекты отличной технологией для создания слабосвязанных программ.
Связь между слабосвязанными компонентами может основываться на множестве механизмов, таких как упомянутый асинхронный стиль связи или стиль синхронной передачи сообщений [7].
Степень слабой связи можно измерить, отметив количество изменений в элементах данных , которые могут произойти в отправляющих или принимающих системах, и определив, будут ли компьютеры по-прежнему продолжать корректно взаимодействовать. Эти изменения включают в себя такие пункты, как: