디자인 패턴 Design Pattern

Design Patterns

 1. 디자인 패턴이란?

  특정 디자인 문제나 상황을 해결하는 데에 효과적인 검증된 설계 템플릿이다. 즉 특정 문제를 해결하기 위한 전략이나 방식을 설명하고 이 패턴들을 수많은 프로젝트와 애플리케이션에서의 경험을 바탕으로 정제되어 왔으며, 따라서 이전에 발생했던 문제들에 대한 효율적인 해결책을 빠르게 찾아 적용할 수 있다.

  

2. GoF 패턴은 어떤 용도로 사용될까?

GoF Pattern Catalogue

 - Creational (생성 패턴) : 객체가 생성되는 방식을 중심으로 설계되어, 객체 생성 과정의 유연성 및 독립성을 증가 시킨다.

 - Structural (구조 패턴) : 클래스나 객체의 구성에 관한 패턴으로 서로 다른 인터페이스나 클래스를 조합하는 방법에 중점을 둔다.

 - Behavioral (행동 패턴) : 객체들 사이의 상호작용이나 책임을 중심으로 설계되는 패턴으로, 객체들 사이의 커뮤니케이션을 개선하거나 객체 간의 책임을 명확히 한다.

	Creational	Structural	Behavioral
Class Level	Factory Method	Adapter	Interpreter Template Method
Object Level	Abstract Factory Builder Prototype Singleton	Adapter Bridge Composite Decorator Facade Flyweight Proxy	Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

 

3. GoF 패턴을 통해 얻을 수 있는 품질은 무엇일까?

  변경용이성 품질 속성을 만족할 수 있다. 디자인 패턴을 적용하면 시간이 지나도 유지보수가 쉽고 확정성이 있고 재사용이 가능한 좋은 코드를 작성할 수 있다. 하지만 상황에 맞지 않게 적용되면 오히려 복잡성을 증가시킬 수 있기 때문에 적절한 패턴을 선택해야 한다.

 

 

Strategy Pattern

 

1. Strategy Pattern(전략 패턴)이란?

  알고리즘의 군을 정의하고 캡슐화 하고, 상호 교환할 수 있도록 한다. 각 전략은 알고리즘을 클라이언트와는 독립적으로 변화시킬 수 있다. 런타임에 알고리즘의 교체가 필요할 때 사용한다.

 

 

2. Strategy Pattern과 Command Pattern의 차이

  Command Pattern은 하나의 명령(기능)을 객체화한 패턴으로 기능을 전달하고 보관할 수 있게 한다. 어떤 명령이든지 간에 단 하나의 실행 명령을 가지고 기능을 실행할 수 있도록 한다. 각 커맨드 클래스는 이 하나의 실행 명령(execute();)를 재정의한다. 이로 인해 If else 구문을 확연히 줄일 수 있다. 또 Undo/Do 등을 큐에 넣어놓고 하나하나 Undo 할 때 동일한 API로 실행 할 수 있도록 하는 패턴이다.

  커맨드 패턴은 기능을 구현할 때 Context와의 강력한 커플링을 가지고 있기 때문에 재사용하기가 어려운 단점이 있다.

  그럼 Mediator 패턴을 적용해보자. 커맨드 클래스들은 메디에이터와만 연관 관계를 가지고 메디에이터는 Context와의 연관관계를 가지게 하여 중간 매개체로서 커플링을 해소할 수 있다.

  전략패턴과 커맨드 패턴 모두 특정한 연산을 캡슐화 하여 객체의 행동을 동적으로 변경하거나 관리하는 데에 도움을 준다. 전략패턴은 행동을 캡슐화 하여 그것들을 동적으로 바꾸려는 경우에 사용하고 커맨트 패턴은 연산을 실행하는 객채와 연산을 요청하는 객체를 분리하는 경우에 사용된다.

 

3. Strategy Pattern과 State Pattern의 차이

  State Pattern은 내부 상태가 변경될때 Object의 동작을 변경할 수 있게 한다. 전략패턴과 상태 패턴 모두 GoF에서 Behavioral Pattern에 속하며 행위를 캡슐화하여 동적으로 객채의 행동을 변경 또는 확장하게 한다.

  전략패턴은 여러 알고리즘(전략) 중에서 하나를 선택하여 객체의 행동을 변경하고 싶을 때 사용하고, 상태 패턴은 객체의 내부 상태에 따라 객체의 행동을 변경하고 싶을 때 사용한다. 전략패턴은 전략을 언제든지 변경할 수 있고, 상태 패턴은 상태가 변하면 그에 따라 객체의 행동도 자동으로 변경된다.

 

4. Strategy Pattern과 Observer Pattern의 차이

   Observer Pattern은 객체 외부에서 관심있는 객체(Subject)의 상태 변화를 관찰하고 변화가 있을 때 등록된 모든 옵저버에게 알린다. 새로운 Subscribe가 추가되더라도 Publisher는 변화가 없다. Subscriber는 알림을 받았을 때 개별적으로 동작하면서 OCP를 만족하게 된다. 

  전략패턴은 객체의 행동을 동적으로 변경하기 위한 패턴이고, 옵저버 패턴은 상태변화를 다른 객체에게 자동으로 알리기 위한 패턴이다.

 

 

 

Template Method Pattern

1. Template Method Pattern이란?

  탬플릿 메서트 패턴은 알고리즘의 순서 또는 구조를 정의해두고 상황에 맞게 서브클래스에서 구체적으로 재정의하는 패턴이다. 즉 상위 클래스에서 알고리즘의 구조와 탬플릿메서드를 정의하고 특정 단계를 서브클래스에서 구현하도록 한다. 

 

 

2. Strategy Pattern과 Template Method Pattern의 차이

   전략 패턴은 context 클래스에서 setStrategy를 통해 동적으로 객체의 행동을 변경하고자 할 때 사용되며, 템플릿 메소드 패턴은 context클래스의 구조는 그대로 유지하면서 일부 단계를 변경하거나 확장하려 할 때 사용한다.

 

 

 

Factory Method Pattern

1. Factory Method Pattern이란?

  객체 생성에 관한 디자인 패턴 중의 하나이며 인스턴스 생성의 책임을 서브클래스에 위임하여 클라이언트와 구체적인 클래스를 분리함으로써 코드의 유연성과 확장성을 향상시킨다. 즉, 객체 생성과 사용을 분리하여 클라이언트는 구체적인 클래스를 알 필요가 없고, 새로운 제품 클래스를 추가할 때 기존 코드를 수정하지 않고 새로운 팩토리 클래스만 추가하면 되므로 OCP를 잘 만족한 패턴이다.

 

2. Factory Method Pattern과 Abstract Factory Method의 차이

 

  두 패턴 모두 객체 생성에 관한 디자인 패턴 중 하나이다. 팩토리 메서드는 하나의 객체 타입에 대해 서브클레스가 구체적인 인스턴스를 생성하도록 하는 것이 목적이다. 추상팩토리 메서드는 관련한 여러 객체의 패밀리를 생성하는 인터페이스를 제공하며, 이 인터페이스를 사용해 구체적인 팩토리를 정의한다. 각 팩토리는 여러 종류의 객체를 생성한다.

  두 패턴 모두 객체 생성 로직의 캡슐화에 초점을 맞추고 있지만 팩토리 메서드는 개별 객체 생성에, 추상팩토리 메소드는 객체 패밀리의 생성에 초점을 맞추고 있다.

 

 

 

Facade Pattern

1. Facade Pattern이란?

  행동패턴 중의 하나로 복잡한 서브시스템의 인터페이스를 간단하게 통합하는 높은 수준의 인터페이스를 제공한다. 이를 동해 복잡한 서브시스템과의 상호작용을 단순화 하고, 클라이언트에세 쉽게 접근 가능한 인터페이스를 제공하는 것이다. 클라이언트는 파사드 인터페이스만 알고있으면 되므로 서브시스템의 복잡성에 대해 알 필요가 없다. 또한 파사드가 서브시스템들 사이의 중재자 역할을 하므로 서브시스템간의 직접적인 의존성이 줄어든다. 파사드 뒤의 서브시스템이 변경 되어도 클라이언트 코드에는 영향을 주지 않는다. 즉 복잡한 시스템을 간단하고 직관적으로 클라이언트가 사용할수 있게 도와준다.

 

2. Facade Pattern과 Mediator Pattern의 차이

  두 패턴 모두 객체들 간의 상호작용을 단순화 하고 중개하는 역할을 한다. 파사드는 클라이언트에게 단순한 인터페이스를 제공하는 것이 주요 목적으로 서브시스템의 복잡성을 숨기며 사용자에게 쉽게 접근할 수 있는 하나의 접점(인터페이스)를 제공한다. 메디에이터는 여러 객체나 클래스 간의 상호작용을 중앙에서 관리하고 조정하는 것이 목적이다. 메디에이터는 객체 간의 직접적인 상호작용이나 참조를 줄이며 서로 독립적으로 동작하도록 도와준다.

  두 패턴 모두 복잡한 상호작용을 단순화 하는 데 중점을 둔다. 하지만 파사드 패턴은 클라이언트와 서브 시스템간의 상호작용을 단순화하는 반면, 메디에이터 패턴은 여러 객체나 클래스 간의 상호 작용을 중앙에서 관리하고 조정하는 데에 중점을 둔다.

 

3. Facade Pattern과 Composite Pattern의 차이

   두 패턴은 모두 GoF에서 구조적 디자인 패턴이다. 컴포지트 패턴은 객체들의 계층 구조를 표현하고, 개별 객체와 그룹 객체를 동일하게 취급하여 일관된 방식으로 사용할 수 있게 한다. 컴포넌트라는 단일 인터페이스를 통해 개별 객체와 복합 객체를 동일하게 취급하고, 이들을 계층구조(트리 구조)를 가지며 재귀적인 구조를 사용한다.
  파사드 패턴을 복잡한 시스템의 사용을 단순화 하는 반면, 컴포지트는 개별 및 복합 객체의 계층 구조를 만들어준다. 구조적 측면에서 파사드는 서브시스템의 단일화된 접점을 제공하고, 컴포지트는 객체의 계층구조를 대상으로 한다.
 

 

Refactoring

 

1. Refactoring의 목적

   동작을 변경하지 않고 소프트웨어의 내부구조를 이해하기 쉽고 적은 비용으로 수정할수 있도록 변경하는 것이 목적이다. 유지보수성을 향상 시킨다. 즉 이해하기 쉽고, 적응성, 확장성, 복잡성(결합도, 응집도)을 개선한다.

 

2. 클래스의 cohesion을 향상하기 위한 리팩토링들

  

3. 클래스의 coupling을 향상하기 위한 리팩토링들
 
4. 타입코드를 클래스로 바꾸는 것 / 타입코드를 서브 클래스로 바꾸는 것 / 타입코드를 상태/전략으로 바꾸는 것 들의 차이
 - 타입코드를 서브 클래스로 바꾸는 것 : 동작에 영향을 미치는 Type code가 불변(Read-only)일때 서브 클래스로 변경하여 상속하게 한다.

 - 타입코드를 상태/전략으로 바꾸는 것 : 동작에 영향을 미치는 Type code가 생성 이후에 변경될 수 있을 때, 전략을 사용하여 알고리즘의 선택을 제어하는 조건를 분할하게 되고, 상태를 사용하여 클래스의 전체 조건(상태)와 알고리즘 선택까지 책임이 있도록 한다.