소프트웨어 모듈 간의 연결을 해제하는 방법

8.1 분해가 전부다

명확성을 위해 설명할 주요 사항을 설명하는 좋은 기사 "객체 지향 시스템의 분리"의 그림입니다.

아직도 애플리케이션 아키텍처 설계가 쉽다고 생각하시나요?

8.2 인터페이스, 구현 숨기기

시스템의 결합을 줄이기 위한 주요 원칙은 OOP의 원칙과 그 뒤에 있는 Encapsulation + Abstraction + Polymorphism의 원칙입니다.

그 이유는 다음과 같습니다.

• 모듈은 서로에 대해 "블랙 박스"여야 합니다(캡슐화) . 이는 한 모듈이 다른 모듈로 "올라가"서는 안 되며 내부 구조에 대해 아무것도 몰라야 함을 의미합니다. 한 하위 시스템의 개체는 다른 하위 시스템의 개체에 직접 액세스해서는 안 됩니다.
• 모듈/하위 시스템은 인터페이스 (즉, 구현 세부 사항에 의존하지 않는 추상화 ) 를 통해서만 서로 상호 작용해야 합니다 . 따라서 각 모듈에는 다른 모듈과 상호 작용하기 위한 잘 정의된 인터페이스가 있어야 합니다.

"블랙 박스"(캡슐화)의 원칙을 통해 다른 하위 시스템과 독립적으로 각 하위 시스템의 구조를 고려할 수 있습니다. "블랙 박스"인 모듈은 비교적 자유롭게 변경할 수 있습니다. 문제는 서로 다른 모듈(또는 모듈과 환경)의 교차점에서만 발생할 수 있습니다.

그리고 이 인터랙션은 가장 일반적인(추상적인) 형태, 즉 인터페이스의 형태로 기술되어야 한다. 이 경우 코드는 인터페이스 계약을 준수하는 모든 구현에서 동일하게 작동합니다. 다형성이라고 하는 통합 인터페이스를 통해 다양한 구현(모듈 또는 개체)으로 작업할 수 있는 기능입니다.

그것이 서블릿이 인터페이스인 이유 입니다. 웹 컨테이너는 서블릿에 대해 아무것도 모릅니다. 웹 컨테이너는 서블릿 인터페이스를 구현하는 일부 객체이기 때문에 그게 전부입니다. 서블릿은 또한 컨테이너의 구조에 대해 조금 알고 있습니다. Servlet 인터페이스는 Java 웹 응용 프로그램이 전 세계를 장악하는 데 필요한 최소한의 상호 작용인 계약, 표준입니다.

다형성은 때때로 잘못 생각되는 것처럼 메서드를 재정의하는 것이 아니라 무엇보다도 동일한 인터페이스 또는 "하나의 인터페이스, 많은 구현"을 가진 모듈/객체의 상호 교환 가능성입니다. 다형성을 구현하기 위해 상속 메커니즘이 전혀 필요하지 않습니다. 일반적으로 상속은 가능할 때마다 피해야 하므로 이를 이해하는 것이 중요합니다 .

인터페이스와 다형성 덕분에 이미 작성된 것을 변경하지 않고 코드를 수정하고 확장할 수 있는 능력(개방형 원칙)이 달성됩니다.

모듈의 상호 작용이 인터페이스의 형태로 독점적으로 설명되고 특정 구현에 연결되지 않는 한 시스템에 대해 절대적으로 "고통 없이" 한 모듈을 동일한 인터페이스를 구현하는 다른 모듈로 교체할 수 있는 기회가 있습니다. 새 것을 추가하여 기능을 확장하십시오.

LEGO 생성자와 같습니다. 인터페이스는 상호 작용을 표준화하고 적절한 커넥터가 있는 모든 모듈을 연결할 수 있는 일종의 커넥터 역할을 합니다.

디자이너의 유연성은 하나의 모듈 또는 부품을 동일한 커넥터(동일한 인터페이스 포함)가 있는 다른 부품으로 간단히 교체할 수 있을 뿐만 아니라 원하는 만큼 새 부품을 추가할 수 있다는 사실에 의해 보장됩니다(동시에 기존 부품은 어떤 식으로든 변경되거나 변경되지 않습니다).

인터페이스를 사용하면 각 하위 시스템을 전체적으로 고려하고 내부 구조를 무시하여 더 간단한 시스템을 구축할 수 있습니다. 그들은 모듈이 상호 작용할 수 있도록 허용하면서 동시에 서로의 내부 구조에 대해 아무것도 알지 못하므로 느슨한 결합의 기초가 되는 최소한의 지식 원칙을 완전히 구현합니다.

인터페이스가 더 일반적/추상적으로 정의되고 인터페이스가 상호 작용에 부과하는 제한이 적을수록 시스템이 더 유연해집니다. 여기에서 SOLID의 원칙 중 하나가 실제로 뒤따릅니다. "두꺼운 인터페이스"에 반대하는 인터페이스 분리 원칙 입니다.

그는 크고 부피가 큰 인터페이스를 더 작고 더 구체적인 인터페이스로 나누어서 작은 인터페이스(모듈에 따라 다름)의 클라이언트가 작업해야 하는 메서드에 대해서만 알 수 있도록 해야 한다고 말합니다.

이 원칙은 다음과 같이 공식화됩니다. "클라이언트는 사용하지 않는 방법(방법에 주의)에 의존해서는 안 됩니다." 또는 "많은 특수 인터페이스가 하나의 범용 인터페이스보다 낫습니다."

모듈의 내부 구조와 구조에 대한 지식을 사용하지 않고 인터페이스, 즉 추상화의 도움으로만 모듈의 상호 작용과 종속성을 설명할 때만 약한 연결성이 제공되며 실제로는 캡슐화가 구현됩니다. 또한 다형성으로 인해 다른 구현을 추가하고 사용하여 시스템 동작을 확장/변경할 수 있습니다. 예, 우리는 다시 OOP - 캡슐화, 추상화, 다형성에 왔습니다.

8.3 외관: 모듈 인터페이스

여기서 숙련 된 프로그래머는 다음과 같이 질문합니다. 디자인이 해당 인터페이스를 구현하는 객체 수준이 아니라 모듈 수준이면 모듈 인터페이스의 구현은 무엇입니까?

답변: 디자인 패턴의 언어로 말하면 모듈 인터페이스의 구현을 담당할 수 있는 특수 객체인 Facade 가 있습니다 . 게이트웨이 접미사(예: MobileApiGateway)가 포함된 개체에서 메서드를 호출하는 경우 이는 파사드일 가능성이 큽니다.

파사드는 특정 하위 시스템과 작업하기 위한 높은 수준의 작업 집합을 축적하는 인터페이스 개체로, 내부 구조와 그 뒤에 있는 진정한 복잡성을 숨깁니다 . 하위 시스템 구현의 변경에 대한 보호를 제공합니다. 단일 진입점 역할을 합니다.

모듈을 설계할 때 인터페이스의 개념을 사용하여 모듈을 분리할 수 있게 해주는 가장 중요한 설계 패턴 중 하나인 "Facade"를 방금 소개했습니다.

또한 "Facade"는 일반 객체와 동일한 방식으로 모듈 작업을 가능하게 하고 모듈을 설계할 때 클래스 설계에 사용되는 모든 유용한 원칙과 기술을 적용합니다.

참고 : 대부분의 프로그래머는 클래스(객체)를 설계할 때 인터페이스의 중요성을 이해하지만 모듈 수준에서도 인터페이스를 사용하는 아이디어를 발견하는 것 같습니다.