저는 디자인 패턴을 처음 사용하고 있으며 일반적으로 어떻게 보이는지 배우려고합니다. 지금 저는 Facade Pattern을 이해하려고합니다. 외관 패턴이 다소 넓은 개념 인 것처럼 느껴 지므로 두 번째 다이어그램이 외관 템플릿의 일부로 간주 될지 궁금합니다.디자인 패턴 - 외관 패턴 이해
: 우리는이 같은 미묘한 다이어그램이있는 경우
그러나 :
나는 전형적인 외관 패턴은 기본적합니다 (외관 인 A-클래스와)과 같습니다 알고
A 클래스는 여전히 Facade-class로 간주 될 것입니까, 아니면 컨텍스트에 의존합니까?
처음에는 외관을 이해하기 위해 리팩토링이라고 생각합니다. 다이어그램 을 facades 클래스없이 모두 상상해보십시오. 고객은 파사드가 관리하는 모든 클래스와 직접 상호 작용해야합니다. 따라서 더 많은 결합으로 더 복잡해질 것입니다.
facade는 클라이언트에게 단순화 된 서비스를 제공하고 (커플 링을 줄임), 뒤에 facade로을 숨 깁니다.
Java에서 가장 좋아하는 예제는 JOptionPane 클래스입니다. 초기 버전의 Java에는 존재하지 않았고, 예/아니오 질문 대화 상자를 작성하려는 경우, 대화 상자, 단추 등의 모든 호출을 관리하고 이벤트를 처리해야했습니다 (클라이언트로서) 이러한 모든 복잡성은 JOptionPane facade 클래스 내부의 정적 메서드로 단순화되었습니다.
는 A-클래스는 여전히 외관 수준으로 간주됩니다하거나 상황에 따라 않습니다 : 여기에 귀하의 질문에 https://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html 이제
에서 UML 다이어그램입니까?
는 A 경우, 효과적으로 고객이 직접 모든 (결합 될)와 상호 작용해야하는없이 B, C, F 및 E의 복잡한 서브 시스템을 사용하는 고객에게 단순화 된 서비스를 제공하고 있습니다 그러면 나는 A이 외관이라고 말할 것입니다.
물론 복합 디자인 패턴으로 작업 할 때 예외가 있지만 일반적으로 특히 외관 클래스는 변경되지 않습니다. 또한 언제든지 새 종속성을 추가 할 수 있습니다. 희망이 도움이됩니다.
나는 상황의 따라 말할 것입니다.
디자인 패턴을 처음 접한 사람은 디자인 패턴을 설명하는 real life stories보다 학습 속도가 빠르고 주제를 이해하는 데 도움이 될 수 있습니다.
예, A 클래스는 클라이언트와 "하위 시스템"간의 유일한 진입 점인 경우 A이 첫 번째 경우와 마찬가지로 두 번째 예제에서 Façade입니다. 숨겨진 서브 시스템이 평면이든 계층 적이든 상관없이 클라이언트 나 실제로 패턴에 중요하지 않습니다.
Façade의 인식 된 유틸리티는 클라이언트에서 추상화 (숨김)되는 복잡성에 다소 비례합니다. 따라서 첫 번째 예제는 네 개의 추가 클래스를 숨기므로보다 유용한 Façade로 간주 될 수 있습니다. 두 번째 예제는 A이없는 경우에만 B 및 C과 상호 작용할 것으로 가정하고 클라이언트의 두 클래스를 숨 깁니다.
흠, 디자인 패턴이 가이드 라인과 같아서 엄격하지 않으므로 컨텍스트에 따라 구체적으로 만들 수 있다고 생각했습니다. – Jesper
컨텍스트에 따라 적용 할 디자인 패턴을 선택할 수 있지만 일반적으로 방금 미리 정의 된 템플릿입니다. 그러나 코드 구조를 프로젝트의 필요에 맞게 조정할 수는 없습니다. –
두 번째 다이어그램이 "맞춤형"외관 다이어그램이 될 수 있다고 말하지만, 다른 패턴일까요? 내 예제와 비슷한 패턴을 찾지 못했기 때문에 패턴이 아닐 수도 있습니다. – Jesper