Facade, Proxy, Adapter 및 Decorator 디자인 패턴의 차이점은 무엇입니까? [닫은]

Facade, Proxy, Adapter 및 Decorator 디자인 패턴의 차이점은 무엇입니까?

나는 분명한 설명을 읽지 않았습니다.

어댑터 는 주어진 클래스 / 객체를 새로운 인터페이스에 적응시킵니다. 전자의 경우에는 다중 상속이 일반적으로 사용됩니다. 후자의 경우, 오브젝트는 적합한 어댑터 오브젝트로 랩핑되어 전달됩니다. 여기서 해결해야 할 문제는 호환되지 않는 인터페이스의 문제 입니다.

Facade 는 복잡한 기능 세트에 대한 간단한 게이트웨이와 비슷합니다. 고객이 걱정을 덜어주는 블랙 박스를 만듭니다 . 즉 , 인터페이스를 더 단순하게 만듭니다 .

프록시 는 프록시 클래스와 동일한 인터페이스를 제공하며 일반적으로 자체적으로 하우스 키핑 작업을 수행합니다. (따라서 무거운 오브젝트의 사본을 여러 개 만드는 대신 X경량 프록시의 사본을 만들어 필요에 따라 통화를 P관리 X하고 변환합니다.) 클라이언트 가 무겁고 복잡한 오브젝트 를 관리하지 않아도되는 문제를 해결하고 있습니다 .

데코레이터 는 오브젝트에 더 많은 화약을 추가하는 데 사용됩니다 (오브젝트라는 용어에 유의하십시오. 일반적으로 런타임에 오브젝트를 동적으로 장식합니다). 객체의 기존 인터페이스를 숨기거나 손상시키지 않고 단순히 런타임에 확장합니다 .

이제 데코레이터가 관련되었으므로 Java와 같은 일부 언어가 단순히 가상 상속 (예 : C ++의 다중 상속)을 허용하지 않는 단어 객체에 대한 강조 이유를 알고 싶을 것입니다. 컴파일 시간.

우리는 여러 상속에 드래그 한 (그리고 지칠대로 지친 다이아몬드) 당신을 위해 밖으로 보이는 것 때문에 유지 mixin -하는 인터페이스의 체인 선형 주문 다중 상속의 문제를 해결하기 위해. 그러나 믹스 인은 잘 섞이지 않습니다. 그리고 우리는 특성으로 끝납니다 -그렇습니다 . C ++의 템플릿 매개 변수에서 항상 팝업 되는 상태가없는 작은 동작 덩어리 . 특성은 여러 상속 또는 순서 체인을 사용하지 않고 우아한 방식으로 구성 및 동작 분해 문제를 해결하려고 시도합니다.

정면

예를 들어 API를 더 쉽게 호출하기 위해 파사드를 사용할 수 있습니다. 원격 정면 의이 예를 살펴보십시오 . 여기서 아이디어는 서버에서 코드의 전체 구현이 클라이언트에서 숨겨져 있다는 것입니다. 클라이언트는 서버에서 1 개 이상의 API를 호출 할 수있는 1 개의 API 메소드를 호출합니다.

어댑터

이것의 좋은 예를 찾을 수 있습니다 여기에 위키 백과에. 클라이언트 객체 Source는 다른 객체 Target에서 메소드를 호출하려고 하지만 다른 객체의 인터페이스는 클라이언트가 기대하는 것과 다릅니다.

어댑터 오브젝트를 입력하십시오.

Source객체 에서 호출을 받아 장면 뒤에서 Target사용해야 하는 메소드를 호출 할 수 있습니다.

Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)

프록시에 관해서는이 디자인 패턴에 대한 경험이 없습니다.