정의 일련의 핸들러를 따라 요청을 전달할 수 있는 행동 디자인 패턴 요청을 받으면 각 핸들러는 요청을 처리할지 아니면 체인의 다음 핸들러로 전달할지 결정 온라인 주문 시스템 있다고 가정하자. 1. 인증된 사용자만 주문을 생성한다. 2. 관리자는 모든 주문에 대한 액세스 권한이 있다. 시간이 흐른 후 몇가지를 추가 구현 하였다. 3. 유효성 검사 단계를 추가 4. 동일한 IP 주소에서 오는 반복적으로 실패한 요청을 필터링 (무차별 암호 해독 문제 처리) 5. Caching ( performance 향상) 문제점 새로운 기능을 추가할 때마다 코드가 점점 많아짐. 하나의 검사를 변경 하면 다른 검사에 영향을 주기도 함. 일부 기능 (Aunthentication) 만 재사용 하려면 코드를 복사해 가야함. 이로인..

어떤 객체를 사용하고자 할때, 객체를 직접적으로 참조 하는것이 아니라, 해당 객체를 대행(대리, proxy)하는 객체를 통해 대상객체에 접근 하는 패턴 아래와 같은 경우에 사용된다. 지연 초기화 액세스 제어 원격 서비스의 로컬 실행 로깅 요청 캐싱 스마트 참조 class diagram 어떤 class 의 method 이전과 이후에 특정 작업(Logging) 을 하는 것을 proxy 로 처리해보자 이전에 사용한 flyweight 와 함께 사용해 보자 flyweight 관련 코드 public class HeavyObject { private readonly string _name; private readonly int _age; public HeavyObject(string name, int age) { T..

동일하거나 유사한 객체들 사이에 가능한 많은 데이터를 서로 공유하여 사용하도록 하여 메모리 사용량을 최소화하는 소프트웨어 디자인 패턴이다. class diagram 예제 public class HeavyObject { private readonly string _name; private readonly int _age; public HeavyObject(string name, int age) { Thread.Sleep(TimeSpan.FromSeconds(1)); _name = name; _age = age; } public void Execution() { Console.WriteLine($"Name : {_name} , Age : {_age}, !! Long live Ukraine !! хай жив..

라이브러리, 프레임워크 또는 기타 복잡한 클래스 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴 전화로 주문하기 복잡한 프레임워크에 속하는 여러 개체들을 이용하여 코드를 초기화 하고 작동시켜야 한다고 가정해보자 아래와 같은 과정을 모든 개체에 해 주어야 한다. 올바른 순서로 개체 초기화 개체간 종속성을 추적 올바른 순서로 메서드를 실행 결과적으로 클래스의 비즈니스 논리가 타사 프레임워크 클래스의 구현 세부 정보와 밀접하게 연결되어 이해하고 유지 관리하기가 어렵다. 이럴 경우 facade 패턴을 통해 문제를 해결 한다. class diagram 어느때 사용해야 하는가? 복잡한 하위 시스템에 대한 제한적이지만 간단한 인터페이스가 필요한 경우 하위 시스템을 계층으로 구성하려는 경우 주요장점 패턴..

주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있다. 옷을 입는 것은 데코레이터의 좋은 예 추우면 스웨터를 입고 위에 재킷을 입을 수도 있다. 또 비가 오면 비옷을 입을 수 있다. 모든 옷은 기본 행동을 확장 하지만 자신의 일부는 아니다. 필요하지 않으면 쉽게 옷을 벗을 수 있다. class diagram 코드를 손상시키지 않고 런타임에 개체에 추가 동작을 할당할 수 있어야 하는 경우 데코레이터 패턴을 사용 상속을 사용하여 개체의 동작을 확장하는 것이 어색하거나 불가능할 때 데코레이터 패턴을 사용 아래 코드는 대검과 단검에 추가적인 효과를 주어 무기를 강화 시키는 것이다. 독과 대못을 추가 할 수 있고 이 기능..

객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한다. 위와 같이 특정 제품들을 모아놓은 box 의 총 가격을 계산한다고 가정하자 각각을 다 풀어서 계산 할 수 있지만 프로그램상에서는 다음과 같은 과정이 필요하다. 각 class 들의 특성(사용법) 및 method 를 알아야 한다. 각 class 들의 가격을 담당하는 특성 및 interface 를 client 가 알고 있어야한다. 각 class 들의 가격은 최종 가격일 수도 있고 client 에서 다시 계산해줘야 할 수도 있다. 위와 같은 과정을 거쳐야 해당 제품의 가격을 알 수 있다. 이건 너무 복잡하고 힘든 과정이다. 총 가격을 계산하는 방법을 선언하는 공통 인터페이스를 통해..