Слабая связь

редактировать
Для использования в других целях, см Слабая связь (значения).

В вычислительных и системе проектирования слабосвязанная система является одним

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

СОДЕРЖАНИЕ

  • 1 Преимущества и недостатки
  • 2 В интеграции
    • 2.1 Способы уменьшения сцепления
  • 3 В программировании
    • 3.1 Другие формы
    • 3.2 Связь элементов данных измерения
  • 4 См. Также
  • 5 ссылки

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

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

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

В интеграции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другие формы

Языки компьютерного программирования, имеющие представления либо о функциях как базовом модуле (см. Функциональное программирование ), либо о функциях как объектах, предоставляют прекрасные примеры слабосвязанного программирования. Функциональные языки имеют шаблоны продолжений, замыканий или генераторов. См. Clojure и Lisp как примеры языков программирования функций. В объектно-ориентированных языках, таких как Smalltalk и Ruby, есть блоки кода, а в Eiffel есть агенты. Основная идея состоит в том, чтобы объективировать (инкапсулировать как объект) функцию, независимую от какой-либо другой включающей концепции (например, отделить функцию объекта от любого прямого знания окружающего объекта). См. Раздел « Первоклассная функция» для дальнейшего понимания функций как объектов, которые квалифицируются как одна из форм первоклассных функций.

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

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

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

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

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

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

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

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

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

Последняя правка сделана 2023-04-17 01:56:37
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте