직접적인 종속성을 메시징으로 대체
때때로 모듈은 일부 이벤트/변경 사항이 발생했음을 다른 사람들에게 알리기만 하면 되며 나중에 이 정보에 어떤 일이 발생하는지는 중요하지 않습니다.
이 경우 모듈은 "서로에 대해 알" 필요가 전혀 없습니다. 즉, 직접 링크를 포함하고 직접 상호 작용하지만 메시지 (메시지) 또는 이벤트 (이벤트)를 교환하는 것으로 충분합니다.
때로는 메시징을 통한 모듈 통신이 직접 종속성보다 훨씬 약한 것처럼 보입니다. 실제로 메서드가 호출되지 않기 때문에 클래스에 대한 정보가 없습니다. 그러나 이것은 환상에 지나지 않습니다.
메소드 이름 대신 로직이 메시지 유형, 해당 매개변수 및 전송된 데이터에 연결되기 시작합니다. 이러한 모듈의 연결이 번집니다.
이전에는 다음과 같았습니다. 우리는 메서드를 호출합니다. 연결이 있고 메서드를 호출하지 않습니다. 연결이 없습니다. 이제 모듈 A가 메시지에서 약간 다른 데이터를 보내기 시작했다고 상상해 보십시오. 동시에 이러한 메시지에 의존하는 모든 모듈이 제대로 작동하지 않습니다.
이전에 새 사용자를 추가할 때 인증 모듈이 USER_ADDED 메시지를 보냈고 업데이트 후 등록을 시도할 때 이 메시지를 보내기 시작했으며 추가로 성공적인 등록 여부를 매개변수에 표시했다고 가정합니다.
따라서 메시지 메커니즘을 매우 유능하게 구현하는 것이 매우 중요합니다. 이에 대한 다양한 템플릿이 있습니다.
관찰자. 많은 모듈이 하나의 주 상태에 의존하는 일대 다 종속성의 경우에 사용됩니다. 메일링 메커니즘을 사용합니다. 즉, 메인 모듈은 단순히 동일한 메시지를 모든 구독자에게 보내고 이 정보에 관심이 있는 모듈은 "구독자" 인터페이스를 구현하고 메일링 리스트에 가입합니다.
이 접근 방식은 사용자 인터페이스가 있는 시스템에서 널리 사용되므로 응용 프로그램(모델)의 핵심이 독립적으로 유지되는 동시에 관련 인터페이스에 무언가 변경되어 업데이트가 필요함을 알릴 수 있습니다.
여기에서 메시지 형식은 운영 체제 수준에서 표준화되며 개발자는 이전 버전과의 호환성과 우수한 문서를 관리해야 합니다.
메시지 배포를 통한 상호 작용 구성에는 추가 "보너스"가 있습니다. "게시된"(즉, 전송된) 메시지에 대한 "구독자"의 선택적인 존재입니다. 이와 같이 잘 설계된 시스템에서는 모듈을 언제든지 추가/제거할 수 있습니다.
메시징 버스
메시지 교환을 구성하고 이를 위해 중재자 패턴을 다른 방식으로 사용할 수 있습니다 .
모듈 간에 다대다 종속성이 있을 때 사용됩니다. 중재자는 모듈 간의 통신에서 중개자 역할을 하며 통신 센터 역할을 하고 모듈이 명시적으로 서로를 참조할 필요가 없습니다.
결과적으로 모듈 간의 상호 작용("all with all")은 모듈과 중개자 간의 상호 작용("one with all")으로 대체됩니다. 중재자는 여러 모듈 간의 상호 작용을 캡슐화한다고 합니다.
이것은 소위 스마트 중개자 입니다 . 개발자가 특정 메시지 수신을 켜거나 꺼서 개별 모듈의 동작에 영향을 미치는 목발을 추가하기 시작하는 곳이 가장 많습니다.
전형적인 실제 사례는 공항 교통 통제입니다. 항공기의 모든 메시지는 항공기 간에 직접 전송되는 대신 컨트롤러의 관제탑으로 이동합니다. 그리고 관제사는 이미 어떤 비행기가 이륙하거나 착륙할 수 있는지에 대한 결정을 내리고 비행기에 메시지를 보냅니다.
중요한! 모듈은 단순한 메시지뿐만 아니라 명령 개체도 서로 보낼 수 있습니다. 이러한 상호 작용은 명령 템플릿 으로 설명됩니다 . 결론은 특정 작업을 별도의 개체로 수행하라는 요청을 캡슐화하는 것입니다.
실제로 이 개체에는 단일 execute() 메서드 가 포함되어 있어 이 작업을 다른 모듈에 전달하여 매개 변수로 실행하고 일반적으로 일반 개체에서 수행할 수 있는 명령 개체로 모든 작업을 수행할 수 있습니다.
데메테르의 법칙
Demeter의 법칙은 암시적 종속성의 사용을 금지합니다. "객체 A가 객체 B에 액세스할 수 있고 객체 B가 객체 C에 액세스할 수 있는 경우 객체 A는 객체 C에 직접 액세스할 수 없어야 합니다."
이는 코드의 모든 종속성이 "명시적"이어야 함을 의미합니다. 클래스/모듈은 작업에서 "자신의 종속성"만 사용할 수 있으며 이를 통해 다른 것으로 올라가서는 안 됩니다. 좋은 예는 3계층 아키텍처입니다. 인터페이스 계층은 논리 계층과 함께 작동해야 하지만 데이터베이스 계층과 직접 상호 작용해서는 안 됩니다.
간단히 말해서, 이 원칙은 다음과 같이 공식화됩니다. "친구의 친구가 아닌 직계 친구와만 상호 작용하십시오." 이렇게 하면 코드의 일관성이 줄어들고 디자인의 가시성과 투명성이 높아집니다.
Demeter의 법칙은 이미 언급한 "최소 지식의 원칙"을 구현합니다. 이는 느슨한 결합의 기초이며 객체/모듈이 다른 객체/모듈의 구조 및 속성에 대해 가능한 한 적은 세부 사항을 알아야 한다는 사실로 구성됩니다. 자체 구성 요소를 포함하여 일반적으로 모든 것 .
삶의 비유 : 개가 뛰기를 원한다면 발을 명령하는 것은 어리석은 일이며 개에게 명령을 내리는 것이 더 낫습니다.
상속 대신 구성
이것은 매우 크고 흥미로운 주제이며 최소한 별도의 강의가 필요합니다. 합의에 도달 할 때까지 인터넷에서이 주제에 대해 많은 사본이 손상되었습니다. 우리는 상속을 최소로, 구성을 최대로 사용합니다.
요점은 상속이 실제로 클래스 간에 가장 강력한 연결을 제공하므로 피해야 한다는 것입니다. 이 주제는 Herb Sutter의 기사 " Prefer Composition Over Inheritance "에서 잘 다룹니다.
디자인 패턴을 배우기 시작하면 개체 또는 개체의 내부 구조 생성을 제어하는 전체 패턴을 보게 됩니다. 그런데 이 맥락에서 저는 게임에서 나온 Delegate/Delegate 패턴 과 Component 패턴에 주목하라고 조언할 수 있습니다 .
패턴에 대해서는 잠시 후에 더 자세히 이야기하겠습니다.
GO TO FULL VERSION