객체가 기능을 수행하는 모든 정보들을 캡슐화 하는 행동 패턴 작업을 요청하는 클래스와 수행하는 클래스를 분리 큐에 커맨드를 순서대로 저장 독립적인 클래스가 많으므로 구현 및 유지보수해야 되는 클래스가 많다. 증권사를 예를들어 고객이 요구하면 (command) 중개사 (invoker)는 고객의 요청을 받아 (ConcreteCommand) 캡슐화해 큐에 넣음 이후, 거래하는 어플을 통해 요청을 처리 (Receiver) 1. 예제 1) 2. 예제 2) 3. 사례 : 증권거래소

행위 패턴 : 객체의 역할에 초점을 둠. 더 큰 기능을 구현하기 위해 객체 간의 상호 작용을 중시 객체(서브젝트)는 자식(옵서버)을 모니터링, 관리 옵서버는 서브젝트의 상태에 따라 자신의 객체 상태를 변경하거나 필요한 연산을 수행 (1:N 관계) 예를 들면 유투브 채널은 서브젝트, 구독자는 옵서버. 유투브 채널에 글이 올라오면 알림을 통해 구독자가 소식을 전해들음 옵서버 디자인 패턴에서 push는 통보 (서브젝트가 옵저버), pull은 부탁 (옵저버가 서브젝트) 옵서버의 잠점은 느슨한 결합 원칙을 따름 -서브젝트와 옵서버가 서로 독립적이며, 때문에 옵서버는 필요 시 어디에서도 재사용 및 추가 가능 1. 예제 1) 2. 사용 사례 : 유튜브

ㅇ 영화 제작사(클라이언트)가 배우한테 직접 접근하지 않고 에이전트(프록시) 를 통해서 연락함 ㅇ 웹 관점에서는 클라이언트가 웹사이트에 접송하면 프록시 서버에 웹페이지 등의 리소스를 요청. 프록시 서버는 요청을 철하여 클라이언트에 다시 전달 ㅇ 프록시와 퍼사드는 비슷하지만 프록시는 객체 사이의 중재자 역할. 퍼사드는 하나의 통합된 간단한 인터페이스 1. 예시1) 영화제작사 2. 예시2) 백화점에서 현금 카드로 결제시

ㅇ 퍼사드 디자인 패턴은 facode 로 얼굴 처럼 내부보다 외관에 신경 (앞단에 더 집중 : 고객) ㅇ 복잡한 내부 시스템 로직을 감추고 클라이언트가 쉽게 시스템을 접근할 수 있는 인터페이스를 제공 ㅇ 단일 인터페이스 객체로 복잡한 서브시스템을 대체 ㅇ 외부에서 보기에 깔끔하도록 복잡한 서브시스템을 감싼다 ㅇ 클라이언트가 특정 작업을 수행할 때 모든 관련 서브시스템에 요청하지 않고 메인 인터페이스(퍼사드)에만 요청 1. 퍼사드 디자인 패턴 예시 : 웨딩플레너 - 예시로 웨딩플레너 (퍼사드) 에게 부탁하면 결혼 준비 다 해줌 - 클라이언트 : 고객 - 퍼사드 : 웨딩플레너 - 서브시스템 : 음식, 꽃 장식 등등 담당하는 업체

ㅇ 제일 많이 쓰는 디자인 패턴 ㅇ 팩토리 패턴이란 다른 클래스의 객체를 생성하는 클래스를 말한다 (ex) a 클래스 하나로 b, c 클래스의 내용까지 표현)ㅇ 예시로 공장이라는 클래스 (a) 에 인형 만드는 기계 (b)가 있었다. 근데 갑자기 가구 만드는 기계 (c)를 추가하기로 했다. c는 간단하게 추가만 하면 됨 ㅇ 객체 생성과 클래스 구현을 나눠 상호 의존도를 줄인다 ㅇ 간단하게 팩토리에 새로운 클래스 추가 가능 1. 심플 팩토리 패턴 예시

1. 싱글톤 디자인 패턴 기본 ㅇ 조건을 통해 동시요청의 충돌을 막음 ㅇ 싱글톤 패턴은 단 한개의 객체만을 허용하는 패턴 ㅇ 동일한 리소스에 대한 동시요청의 충동를 막기위해 사용 ㅇ 예를 들면. 객체가 있으면 반환 없으면 미반환 코드 수행 ㅇ 단점 : - 모든 클래스 간 상호관계가 복잡해짐 - 전역 변수 수정이 의도치 않게 다른 클래스에도 영향을 줌 ㅇ 생성 패턴 : 객체가 생성되는 방식이 중요한거지 생성되는 세부 과정은 숨기고 객체 형태와 독립 구조 지원 예시 1) 2. 게으른 초기화 ㅇ 객체를 생성할 때 무조건 불러오는게 아니라, 조건을 부여해서 상황에 맞게 메소드 형태에서 객체를 생성하게끔 만듦ㅇ 싱글톤 패턴은 단 한 개의 객체만 생성 3. 모노스테이트 싱글톤 패턴 ㅇ 원래는 한 개의 클래스 객체만..