느슨한 결합

컴퓨팅 및 시스템 설계에서 느슨하게 결합된(loosely coupled) 시스템은 다음 중 하나이다.

구성 요소가 서로 약하게 연관되어(분리될 수 있는 관계를 가짐) 한 구성 요소의 변경이 다른 구성 요소의 존재나 성능에 최소한의 영향을 미치는 시스템.
각 구성 요소가 다른 개별 구성 요소의 정의에 대해 거의 또는 전혀 알지 못하거나 사용하지 않는 시스템. 하위 영역에는 클래스, 인터페이스, 데이터 및 서비스의 결합이 포함된다.^[1] 느슨한 결합은 강한 결합의 반대이다.

장점과 단점

느슨하게 결합된 시스템의 구성 요소는 동일한 서비스를 제공하는 대체 구현으로 교체될 수 있다. 느슨하게 결합된 시스템의 구성 요소는 동일한 플랫폼, 언어, 운영체제, 또는 빌드 환경에 덜 구속된다.

시스템이 시간적으로 분리되면 트랜잭션 무결성을 함께 제공하기 어렵고, 추가적인 조정 프로토콜이 필요하다. 다른 시스템 간의 데이터 복제는 느슨한 결합(가용성 측면)을 제공하지만, 일관성 유지에 문제를 야기한다.

통합에서

더 넓은 분산 시스템 설계에서 느슨한 결합은 트랜잭션, 메시지 지향 미들웨어가 제공하는 큐, 그리고 상호 운용성 표준을 사용하여 달성된다.^[2]

느슨한 결합을 촉진하는 네 가지 유형의 자율성은 참조 자율성, 시간 자율성, 형식 자율성 및 플랫폼 자율성이다.^[3]

느슨한 결합은 서비스 지향 아키텍처의 아키텍처 원칙이자 설계 목표이다. 느슨한 결합의 11가지 형태와 그에 대응하는 강한 결합은 다음과 같다:^[4]

중재자를 통한 물리적 연결,
비동기 통신 방식,
데이터 모델에서 간단한 공통 타입만 사용,
약한 타입 시스템,
데이터 중심적이고 자체 포함된 메시지,
프로세스 논리의 분산 제어,
동적 바인딩 (서비스 소비자 및 공급자 간),
플랫폼 독립성,
시스템 수준 트랜잭션 대신 비즈니스 수준 보상,
다른 시점에 배포,
버전 관리에서 암묵적인 업그레이드.

엔터프라이즈 서비스 버스(ESB) 미들웨어는 여러 차원에서 느슨한 결합을 달성하기 위해 발명되었다.^[5] 그러나 과도하게 설계되거나 잘못 배치된 ESB는 오히려 원치 않는 강한 결합과 중앙 집중형 아키텍처 핫스팟을 만들어낼 수도 있다.

이벤트 기반 아키텍처도 느슨한 결합을 촉진하는 것을 목표로 한다.^[6]

결합 감소 방법

인터페이스의 느슨한 결합은 표준 형식(예: XML 또는 JSON)으로 데이터를 게시함으로써 향상될 수 있다.

프로그램 구성 요소 간의 느슨한 결합은 매개변수에 표준 데이터 유형을 사용함으로써 향상될 수 있다. 사용자 지정 데이터 유형이나 객체를 전달하려면 두 구성 요소가 사용자 지정 데이터 정의를 알아야 한다.

서비스의 느슨한 결합은 서비스에 전달되는 정보를 핵심 데이터로 줄임으로써 향상될 수 있다. 예를 들어, 편지를 보내는 서비스는 고객 식별자만 전달하고 고객 주소는 서비스 내에서 얻을 때 가장 재사용성이 높다. 이렇게 하면 서비스가 특정 순서(예: GetCustomerAddress, SendLetter)로 호출될 필요가 없어 서비스가 분리된다.

프로그래밍에서

결합은 한 구성 요소가 다른 구성 요소에 대해 직접적으로 아는 정도를 나타낸다. 컴퓨팅에서 느슨한 결합은 비캡슐화와 대비되는 캡슐화로 해석된다.

강한 결합의 예는 의존적인 클래스가 필요한 동작을 제공하는 구체적인 클래스에 직접 포인터를 포함하는 경우이다. 이 의존성은 의존적인 클래스를 변경하지 않고는 대체되거나 "서명"이 변경될 수 없다. 느슨한 결합은 의존적인 클래스가 인터페이스에만 포인터를 포함하고, 이 인터페이스는 하나 또는 여러 구체적인 클래스에 의해 구현될 수 있을 때 발생한다. 이를 의존성 역전이라고 한다. 의존적인 클래스의 의존성은 인터페이스에 의해 지정된 "계약"에 있으며, 이는 구현 클래스가 제공해야 하는 메서드 및 속성의 정의된 목록이다. 따라서 인터페이스를 구현하는 모든 클래스는 해당 클래스를 변경할 필요 없이 의존적인 클래스의 의존성을 충족시킬 수 있다. 이는 소프트웨어 설계에서 확장성을 허용한다. 인터페이스를 구현하는 새로운 클래스는 종속 클래스를 변경할 필요 없이 일부 또는 모든 상황에서 현재 종속성을 대체하도록 작성될 수 있다. 새로운 클래스와 이전 클래스는 자유롭게 교환될 수 있다. 강한 결합은 이를 허용하지 않는다.

다음은 의존적 클래스와 필요한 동작을 제공하는 구체적 클래스 집합 간의 느슨한 결합을 보여주는 UML 다이어그램이다.

비교를 위해, 이 다이어그램은 의존적 클래스와 제공자 간의 강한 결합을 가진 대체 설계를 보여준다.

다른 형태

함수를 핵심 모듈로 삼거나(참고: 함수형 프로그래밍) 함수를 객체로 삼는 개념을 가진 컴퓨터 프로그래밍 언어는 느슨하게 결합된 프로그래밍의 훌륭한 예시를 제공한다. 함수형 언어는 Continuation, 클로저 또는 생성자 패턴을 가지고 있다. 클로저 및 리스프를 함수형 프로그래밍 언어의 예시로 보라. 스몰토크 및 루비와 같은 객체 지향 언어는 코드 블록을 가지고 있으며, 에펠은 에이전트를 가지고 있다. 기본 아이디어는 다른 어떤 둘러싸는 개념(예: 객체 함수를 둘러싸는 객체에 대한 직접적인 지식으로부터 분리)과 독립적으로 함수를 객체화(객체로 캡슐화)하는 것이다. 함수를 객체로 이해하는 더 깊은 통찰력을 얻으려면 일급 함수를 보라. 이것은 일급 함수의 한 형태이다.

예를 들어, 객체 지향 언어에서 객체의 함수가 객체로 참조될 때(둘러싸는 호스트 객체에 대한 지식으로부터 자유롭게) 새로운 함수 객체는 전달, 저장 및 나중에 호출될 수 있다. 이 함수 객체를 받은 객체는 둘러싸는 호스트 객체에 대한 직접적인 지식 없이도 자신에게 편리한 시간에 포함된 함수를 안전하게 실행(호출)할 수 있다. 이러한 방식으로 프로그램은 함수 객체의 체인 또는 그룹을 실행할 수 있으며, 둘러싸는 호스트 객체에 대한 직접적인 참조로부터 안전하게 분리될 수 있다.

전화번호는 훌륭한 비유이며 이러한 분리 정도를 쉽게 설명할 수 있다.

예를 들어, 어떤 개체가 다른 개체에게 특정 작업을 수행하도록 전화번호를 제공한다. 전화가 걸려오면 발신 개체는 효과적으로 "이 작업을 저를 위해 해주세요."라고 말하는 것이다. 분리 또는 느슨한 결합은 즉시 명확해진다. 전화번호를 받는 개체는 전화번호가 어디서 왔는지(예: 번호 제공자에 대한 참조) 알지 못할 수 있다. 반대로, 발신자는 자신이 누구에게 전화를 거는지, 그들이 어디에 있는지, 수신자가 내부적으로 어떻게 작동하는지에 대한 특정 지식으로부터 분리된다.

예를 한 단계 더 나아가면, 발신자는 수신자에게 "이 작업을 저를 위해 해주세요. 끝나면 이 번호로 다시 전화해주세요."라고 말할 수 있다. 수신자에게 제공되는 '번호'를 "콜백"이라고 한다. 다시 말하지만, 이 함수 객체의 느슨한 결합 또는 분리된 특성은 분명하다. 콜백의 수신자는 무엇 또는 누구에게 전화가 걸리는지 알지 못한다. 단순히 전화를 걸 수 있다는 것만 알고 언제 전화할지는 스스로 결정한다. 실제로는 콜백이 처음에 콜백을 제공한 사람에게 조차 아닐 수도 있다. 이러한 간접성은 함수 객체를 느슨하게 결합된 프로그램을 달성하기 위한 훌륭한 기술로 만드는 이유이다.

느슨하게 결합된 구성 요소 간의 통신은 언급된 비동기 통신 방식 또는 동기 메시지 전달 방식과 같은 다양한 메커니즘을 기반으로 할 수 있다.^[7]