2.1 어댑터
어댑터(Adapter)는 특별히 생성된 인터페이스를 통해 수정할 수 없는 개체의 기능 사용을 구성하도록 설계된 구조적 설계 패턴입니다.
공식적인 정의는 조금 까다롭지만, 자신의 말로 설명하면 어댑터는 호환되지 않는 인터페이스를 가진 객체가 함께 작동하도록 허용하는 디자인 패턴입니다 .
특별히 생성된 인터페이스를 통해 수정할 수 없는 개체의 기능 사용을 구성하는 데 사용됩니다 . 필요한 인터페이스가 있는 추가 클래스가 생성되고 이 클래스는 원하는 개체(필수 인터페이스가 없음)의 메서드를 차례로 호출합니다.
중요한! 코드에서 클래스의 접미사 어댑터를 만나면 이 클래스가 어댑터 역할을 하고 위에서 설명한 체계에 따라 작동하는 클래스 그룹과 연결되어 있다고 생각할 권리가 있습니다.
시스템이 필요한 데이터 및 동작을 지원하지만 부적절한 인터페이스가 있는 경우에 사용됩니다 . 어댑터 패턴의 가장 일반적인 용도는 신규 또는 기존 추상 클래스에서 상속되는 클래스를 생성하려는 경우입니다.
강점:
- 다른 외부 클래스를 사용하는 전환은 시스템 자체를 재작업할 필요가 없으며 하나 이상의 어댑터 클래스를 구현하는 것으로 충분합니다.
- 외부 클래스(코드를 변경할 수 없는 라이브러리의 클래스) 구현과의 독립성. 당신의 프로그램은 외부 클래스의 인터페이스로부터 독립적이 됩니다.
2.2 데코레이터
데코레이터는 개체에 추가 동작을 동적으로 연결하기 위한 구조적 디자인 패턴입니다. 데코레이터 패턴은 기능을 확장하기 위해 서브클래싱하는 방법에 대한 훌륭하고 유연한 대안을 제공합니다.
추가 의무를 개체에 동적으로 연결하는 데 사용됩니다 .
많은 분들이 질문하실 것입니다. 어떻게 동적으로(프로그램이 실행되는 동안) 개체에 새 동작을 추가할 수 있습니까? 개체는 조각, 즉 작은 개체로 조립할 수 있습니다. 서블릿의 필터 체인을 기억하십니까? 또는 filter(), map(), list()를 사용하여 쿼리를 작성할 때 Stream API?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);데코레이터 패턴의 강점:
- 개체의 기능을 확장하기 위해 하위 클래스를 만들 필요가 없습니다.
- 새로운 기능을 어디에서나 동적으로 연결하는 기능: ConcreteComponent 개체의 주요 기능 앞이나 뒤에.
2.3 프록시
프록시 는 다른 개체에 대한 액세스를 제어하는 개체를 제공하는 구조적 디자인 패턴으로 모든 호출을 가로채고 전달합니다.
프록시 패턴은 실제 객체 대신 대체 객체를 제공합니다. 이 개체는 원래 개체에 대한 액세스를 제어합니다. 매우 자주 사용됩니다.
Mockito 프레임워크를 사용하고 Mockito.spy() 메서드 또는 @Spy 주석을 사용하여 실제 객체에 대한 호출을 가로챈 방법을 기억하십니까? 그런 다음 원래 개체에 대한 모든 호출이 전달되는 특수 프록시 개체가 생성되었습니다.
그런 다음 개체에 규칙을 추가하여 이러한 호출을 관리할 수 있습니다. 맞습니다. 원래 개체는 변경되지 않으며 개체 작업이 훨씬 더 유연해집니다. 코드에서 프록시 개체를 호출하지 않고 어딘가에 전달할 때 특히 유용합니다. 따라서 우리와 독립적인 두 개체의 통신을 제어합니다.
목적별 프록시 유형 :
- 로깅 프록시 : "제목"에 대한 모든 호출을 해당 매개변수와 함께 기록합니다.
- 원격 프록시 (원격 프록시): 다른 주소 공간이나 원격 시스템에 있는 "주체"와의 통신을 제공합니다. 또한 요청과 해당 인수를 인코딩하고 인코딩된 요청을 실제 "제목"으로 보내는 일을 담당할 수도 있습니다.
- 가상 프록시 (가상 프록시): 실제 "제목"이 실제로 필요할 때만 생성되도록 합니다. 또한 생성을 지연시키기 위해 실제 "제목"에 대한 일부 정보를 캐시할 수 있습니다.
- Copy-on-write : 클라이언트가 특정 작업을 수행할 때 "주체"의 복사본을 제공합니다("가상 프록시"의 특수한 경우).
- 보호 프록시 : 호출자가 요청을 수행하는 데 필요한 권한이 있는지 확인할 수 있습니다.
- Caching Proxy : 계산 결과를 공유할 수 있는 여러 클라이언트에 제공하기 전에 계산 결과를 임시로 저장합니다.
- 스크리닝 프록시: 위험한 클라이언트로부터 "대상"을 보호합니다(또는 그 반대).
- Synchronization Proxy : 비동기 멀티스레드 환경에서 “Subject”에 대한 동기화된 접근 제어를 수행합니다.
- "스마트" 링크 (스마트 참조 프록시): "제목"에 대한 링크가 생성될 때 추가 작업을 수행합니다. 예를 들어 "제목"에 대한 활성 링크 수를 계산합니다.
2.4 다리
브리지 패턴은 "독립적으로 변경할 수 있도록 추상화와 구현을 분리"하는 데 사용되는 구조적 디자인 패턴입니다.
브리지 패턴은 캡슐화, 집계를 사용하고 상속을 사용하여 클래스 간에 책임을 공유할 수 있습니다.
추상화와 구현이 분리되면 독립적으로 변경될 수 있습니다. 즉, 브리지 패턴을 통해 구현하는 경우 인터페이스의 구조를 변경해도 구현의 구조 변경에 방해가 되지 않습니다.
그림과 같은 추상화를 고려하십시오. 도형에는 여러 가지 유형이 있으며 각각 고유한 속성과 방법이 있습니다. 그러나 모든 수치를 하나로 묶는 것이 있습니다. 예를 들어, 각 도형은 스스로 그릴 수 있어야 하고 크기 조절 등이 가능해야 합니다.
동시에 그리는 그래픽은 OS나 그래픽 라이브러리의 종류에 따라 다를 수 있습니다. 도형은 다양한 그래픽 환경에서 스스로 그릴 수 있어야 합니다. 그러나 각 도형에 모든 그리기 방법을 구현하거나 그리기 방법이 바뀔 때마다 도형을 수정하는 것은 현실적이지 않습니다.
이 경우 브리지 패턴이 도움이 되어 다양한 그래픽 환경에서 드로잉을 구현할 새 클래스를 만들 수 있습니다. 이 접근 방식을 사용하면 새 도형을 추가하고 그리는 방법을 매우 쉽게 추가할 수 있습니다.
다이어그램에서 화살표로 표시된 연결은 두 가지 의미를 가질 수 있습니다. a) Liskov 대체 원칙에 따른 "종류" b) 추상화의 가능한 구현 중 하나. 언어는 일반적으로 상속을 사용하여 클래스 계층을 부풀리는 경향이 있는 a)와 b)를 모두 구현합니다.
브리지는 이 문제를 정확히 해결하는 역할을 합니다. 개체는 계층 구조 A와 계층 B의 개체에서 쌍으로 생성되고 계층 A 내의 상속은 Liskov에 따르면 "다양성"의 의미를 가지며 "구현"의 개념에 대해 추상화의 "객체 A에서 쌍을 이룬 객체 B로의 링크가 사용됩니다.
2.5 파사드
Facade 패턴은 시스템의 적절한 개체에 위임하는 단일 개체에 대한 가능한 모든 외부 호출을 줄임으로써 시스템의 복잡성을 숨기는 구조적 디자인 패턴입니다.
예를 들어 해당 하위 시스템에 대한 강력한 결합이 바람직하지 않거나 하위 시스템의 구현이 변경될 수 있는 경우 하위 시스템에 대한 일련의 이질적인 구현 또는 인터페이스로 통합 인터페이스를 제공하는 방법은 무엇입니까?
하위 시스템과의 상호 작용의 한 지점을 정의합니다. 하위 시스템과의 공통 인터페이스를 제공하는 파사드 객체를 정의하고 해당 구성 요소와 상호 작용할 책임을 할당합니다. Facade는 하위 시스템 서비스에 대한 단일 진입점을 제공하는 외부 객체입니다.
다른 하위 시스템 구성 요소의 구현은 비공개이며 외부 구성 요소에 표시되지 않습니다. Facade 개체는 하위 시스템 구현의 변경에 대한 보호 측면에서 변경에 저항하는 GRASP 패턴의 구현을 제공합니다.
중요한! 이 패턴은 일부 개체 그룹을 완전히 숨기고 해당 개체와의 모든 통신을 개체를 통해 전달하려는 경우에 사용됩니다. 개체의 통신 프로세스에 대한 일부 제어를 제공하고 반드시 숨길 필요가 없는 경우 프록시 패턴을 사용하는 것이 좋습니다.