Design Pattern을 공부해보자 3탄

Design Pattern을 공부해보자

커맨드 패턴

커맨드 패턴을 이용하면 요구 사항을 객체로 캡슐화 할 수 있으며, 매개변수를 써서 여러 가지 다른 요구 사항을 집어 넣을 수도 있다. 또한, 요청 내역을 큐에 저장하거나 로그로 기록 할 수 있으며, 작업 취소 기능도 지원 한다.

커맨드 패턴 코드

---

어댑터 패턴

한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환한다. 어댑터를 이용하면, 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있다.

어댑터 패턴에서는 2가지가 존재한다.

1. 객체 어댑터

2. 클래스 어댑터

Java에서는 다중 상속을 지원하지 않기에, 클래스 어댑터는 적용할 수 없습니다.

퍼사드 패턴

어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공할 수 있다.

퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용할 수 있다.

어댑터 패턴과 퍼사드 패턴은 다시 좀 더 봐야 할 것 같다. 유사성이 좀 깊어서 그런지 헷갈린다.

템플릿 메소드 패턴

쉽게 말해 알고리즘의 틀을 만들어 주는 것을 말한다.

public abstract class CaffeineBeverage {

    final void prepareRecipe(){

        boilWater();

        brew();

        pourInCup();

        addCondiments();

    }

}

위에 있는 이 코드 중에 prepareRecipe() 메소드가 바로 템플릿 메소드이다. 알고리즘의 틀을 가지고 있어서 그렇게 불리는 것 같다.

템플릿 메소드 패턴 코드

---

이터레이터 패턴

컬렉션 구현 방법을 노출 시키지 않고, 해당 컬렉션의 모든 항목에 접근 할 수 있는 방법을 제공하는 패턴으로, 반복자 패턴이라 부른다.

여기서 중요한 것은 자바에서는 컬렉션 프레임워크라 불리는 List,Set, Map등에 대해서는 Iterator 인터페이스를 구현하여 메소드로 제공을 한다. 다만, 배열의 경우 직접 작성해야 한다.

배열인지, 리스트인지 사용자는 알 수 없고, 반복자의 동작에만 신경쓰면 되므로 메소드 내용에 관한 캡슐화를 해준다는 장점이 있다.

컴포지트 패턴

객체들을 트리 구조로 구성 하여 부분과 전체를 나타내는 계층 구조로 만들 수 있다. 클라이언트에서 개별 객체와 다른 객체들로 구성된 복합 객체를 똑같이 다를 수 있는 장점이 있다.

특히, 전체 - 부분 관계를 가지는 객체 컬렉션 구조를 만들고, 해당 객체들을 똑같이 처리 하고 싶을 때, 사용하는 패턴이라고 이해하면 된다.

즉, 예시 코드에서는 메뉴 프린팅을 위한 것인데, 메뉴가 아침, 점심이 다르며, 담는 구조 또한 각기 다를 때, 이터레이터 패턴과 결합하여 컴포지트 패턴을 사용 할 수 있다. 단, 이때에 단일 책임의 원칙을 위배 된다.

이터레이터 패턴 코드

스테이트 패턴

객체 내부 상태가 바뀜에 따라 객체의 행동을 바꿀 수 있다. 고로, 객체의 클래스가 변경 되는 것과 같은 효과를 얻을 수 있다.

스테이트 패턴 코드

프록시 패턴

다른 객체를 대변하는 객체를 만들어 주 객체에 대한 접근을 제어 할 수 있다.

• 방화벽 프록시

• 스마트 레퍼런스 프록시

• 캐싱 프록시

• 동기화 프록시

• 복잡도 숨김 프록시

• 지연 복사 프록시

프록시 패턴 참고

• devbox

• palpit

컴바운드 패턴

두 개 이상의 패턴을 결합하여 일반적으로 자주 등장하는 문제들을 해결하는 해법을 제공한다. 특히, MVC 패턴이 이에 속한다. 이미지

MVC pattern

결국, 객체 지향 설계 원칙에 해당하는 부분을 맡는 것이라고 생각한다. 단일 책임원칙이 있는데 이를 잘 만들어 둔 패턴의 하나라고 생각하는데, 실제로 모델 입장에서는 옵저버 패턴이 접목 되어 있으며, 전략 패턴도 들어가 있다. 컨트롤러에서 어떤 뷰를 응답할지에 대한 전략이 녹아 있기 때문이다.

뷰는 사용자에게 보여지고 요청을 받는 프레젠테이션 영역을 담당하고 있기에 하나의 책임을 가지고 있다.

모델은 데이터에 관한 부분에 대해서 책임을 가지고, 컨트롤러 또한 요청/응답 관계에 대한 처리의 책임을 가지고 있다.

이는 초기에는 복잡해 보여도 나중에 갈수록 효율을 가지는 패턴으로 생각한다. 유지보수를 더 쉽게 명확하게 하기 위한 전략도 녹아 있다고 할 수 있으며, 각 자 책임이 분산 되어 어느 한 곳에만 몰려 있지 않아 그러한 점에서 확장도 쉽다.

​