취업과 기본기 튼튼/빽 투더 기본기 (38) 썸네일형 리스트형 [디자인 패턴 10편] 행동 패턴, 스트레티지(Strategy) 1. 개념 스트레티지 패턴은 행동/전략 등 동일계열의 알고리즘들을 인터페이스-캡슐화하고, 알고리즘들을 컴포지션(위임 형태로) 가지는 패턴이다. 1.1. 구조 Context 클라이언트가 직접 사용하는 클래스 Strategy 인터페이스를 위임하고(has) 하고 있음. Strategy 구체적인 알고리즘들의 공통 스펙을 정의하는 클래스 ConcreteStrategy 구체적인 알고리즘들을 구현하는 클래스 1.2. 장점 상황에 따라 사용할 알고리즘을 쉽게 바꿀 수 있다. 알고리즘 구현부와 사용부가 분리되어 있다. 인터페이스로 사용자는 일관성있게 알고리즘을 가져다 쓸 수 있고, 각 알고리즘들은 동일한 인터페이스를 가지되, 각각 목적에 따라 구현은 다르게할 수 있다. 1.3. 단점 다 사용하지 않는 정보들을 모든 알고.. [디자인 패턴 9편] 구조 패턴, 프록시(Proxy) 1. 개념 프록시 패턴은 프록시 객체를 통해 기본 객체에 접근하는 패턴이다. 1.1. 장점 기본 객체의 리소스가 무거운 경우, 프록시 객체에서 간단한 처리를 하거나 기본 객체를 캐싱 처리함으로써 부하를 줄일 수 있다. 기본 객체에 대한 수정 없이, 클라이언트에서의 사용과 기본 객체 사이에 일련의 로직을 프록시 객체를 통해 넣을 수 있다. 프록시는 기본 객체와 요청 사이에 있기 때문에, 일종의 방패(보안)의 역할도 한다. 구조나 코드 구현이 간단함. 1.2. 단점 프록시 객체가 중간에 껴있기 때문에, 간혹 응답이 느려질 수 있다. (캐싱이 안되어있는 초기 사용의 경우) 1.3. 활용 상황 기본 객체가 리소스 집약적인 경우. 자잘한 작업들은 프록시 객체가 처리하게 한다. 기본 객체에 접근을 제어해야하는 경우.. [디자인 패턴 8편] 구조 패턴, 데코레이터(Decorator) 1. 개념 데코레이터 패턴은 기본 객체에 추가적인 기능을 동적으로 유연하게 첨가하는 패턴이다. 1.1. 장점 객체에 동적으로 기능 추가가 간단하게 가능하다. 1.2. 단점 자잘한 데코레이터 클래스들이 계속 추가되어 클래스가 많아질 수 있다. 겹겹이 애워싸고 있기 때문에 객체의 정체를 알기 힘들고 복잡해질 수 있다. 1.3. 활용 상황 객체가 상황에 따라 다양한 기능이 추가되거나 삭제되어야 할 때. 2. 구조 Component ConcreteComponent 과 Decorator 가 구현할 인터페이스다. 두 객체를 동등하게 다루기 위해 존재함 ConcreteComponent Decorate 를 받을 객체다. 즉, 기능 추가를 받을 기본 객체 Decorator Decorate 를 할 객체의 추상 클래스다. .. [디자인 패턴 7편] 구조 패턴, 컴퍼지트(Composite) 1. 개념 컴퍼지트 패턴은 단일 객체와 그 객체들을 가지는 집합 객체를 같은 타입으로 취급하며, 트리 구조로 객체들을 엮는 패턴이다. 1.1. 장점 객체들이 모두 같은 타입으로 취급되기 때문에 새로운 클래스 추가가 용이하다. 단일객체, 집합객체 구분하지 않고 코드 작성이 가능하다. 1.2. 단점 설계를 일반화 시켜 객체간의 구분, 제약이 힘들다. 1.3. 활용 상황 객체들 간에 계급 및 계층구조가 있고 이를 표현해야할 때 클라이언트가 단일 객체와 집합 객체를 구분하지 않고 동일한 형태로 사용하고자 할 때 2. 구조 Component Leaf와 Composite 가 구현해야하는 Interface 로, Leaf 와 Composite 는 모두 Component 라는 같은 타입으로 다뤄진다. Leaf 단일 객체.. [디자인 패턴 6편] 구조 패턴, 어댑터(Adapter) 1. 개념 어댑터 패턴은 서로 다른 인터페이스를 가진 두 클래스를 어댑터 클래스로 인터페이스를 통일 시켜 사용하는 방법이다. 1.1. 장점 기존 클라이언트 단의 코드 수정 최소화. 클라이언트는 연동부분을 몰라도, 새로운 코드의 기능을 일관되게 사용가능. 1.2. 단점 어댑터 클래스에서 통일 시켜주는 부분을 하나씩 구현해야 함. 1.3. 활용 상황 기존의 코드에 새로운 코드(써드파티 라이브러리 등)을 연동하여 사용하고 싶은데, 두 코드의 인터페이스가 달라, 이를 하나로 통일하여 사용하고 싶을 때. 아래 예의 경우, 기존의 클라이언트 단 코드에 맞춰 통일함. 2. 구조 3. 코드 3.1. 적용 전/후 모습 먼저 사전에 mp3 포맷만 지원하는 AudioPlayer 가 정의되어있고, 메인에서는 다음과 같이 사용.. [디자인 패턴 5편] 생성 패턴, 추상 팩토리 메쏘드 (Abstract Factory) 1. 개념 추상 팩토리 메쏘드는, 기존 팩토리 메쏘드 방식에서 팩토리의 상위 팩토리를 통해 구체적인 팩토리를 생성한다. 1.1. 장점 팩토리 메쏘드와 동일하다. 다만 팩토리의 종류가 늘었으므로, 커버 범위가 더 넓어졌다고 해야할까. 객체의 생성을 한 군데에서 할 수 있다. 1.2. 단점 팩토리 메쏘드와 동일하다. 1.3. 활용 상황 팩토리 메쏘드를 쓰던 상황에서, 팩토리의 종류를 늘려야 할 때. 2. 구조 3. 코드 먼저 클라이언트는 다음과 같이 사용할 수 있다. // AbstractFactoryPatternDemo.java public class AbstractFactoryPatternDemo { public static void main(String[] args) { // 팩토리의 팩토리인 Facto.. [디자인 패턴 4편] 생성 패턴, 빌더 (Builder) 여기서 말하는 빌더 패턴은 GoF 의 책에서 소개하는 Builder 패턴이 아니라, Effective JAVA 2/E 에서 소개되는 Builder 패턴입니다. 개인적으로 후자가 더 많이 쓰이는 것을 보았어서, Effective JAVA 에서 소개되는 패턴을 기준으로 정리합니다. 1. 개념 빌더 패턴은 생성 인자가 많을 시, 빌더 객체를 통해 구체적인 객체를 생성한다. 1.1. 장점 객체 생성에 필요한 파라미터의 의미를 코드 단에서 명확히 알 수 있다. (가독성이 좋다.) 생성에 필요한 파라미터가 추가될 때 마다, 생성자 오버로딩을 안해도 된다. 1.2. 단점 추가적인 빌더 클래스 구현해야 함. 1.3. 활용 상황 생성자 인자가 많은 경우. 예를 들면 다음 코드보다, WebBrowser browser = .. [디자인 패턴 3편] 생성 패턴, 팩토리 메쏘드 (Factory) 1. 개념 팩토리 패턴은 인터페이스로 객체들을 정의하고, 팩토리가 인스턴스를 생성하는 패턴이다. 1.1. 장점 객체 생성 하는 코드를 분리하여 클라이언트 코드와 결합도(의존성)를 낮춤. 코드에 변경이 필요할 시, 객체 생성 클래스만 수정하면 된다. 인터페이스를 바탕으로 유연성과 확장성이 뛰어난 코드 제작이 가능 객체의 자료형이 하위 클래스 의해서 결정됨 확장에 용이함 상위 클래스에서 그 객체에 대한 정확한 타입을 몰라도 된다. SOLID 원칙 중 DIP (Dependency Inversion Principle, 의존 관계 역전 원칙) 를 성립함 1.2. 단점 새로 생성할 객체의 종류가 늘어날 때마다, 클래스가 많아짐. 1.3. 활용 상황 딱히 구분없이 일반적으로 많이 사용됨. 대표적인 것이 JAVA 의 .. 이전 1 2 3 4 5 다음
하나씩 점을 찍어 나가며
