ㅇ 유연하게 만들기 (재사용이 쉽다) ㅇ 융통성있게 만들기 (간단한 수정 시 많은 부분을 손 안봐도 됨) ㅇ 강건하게 코드 짜기 (수정해도 시스템이 취약해지지 않는다) ㅇ 점성이 낮게 만들기 (결함에 대한 수정이 어렵지 않게 만들기) ㅇ 코드가 복잡하면 안됨 ㅇ 비슷한 성공 사례가 있어도 너무 그대로 쓰면 안됨. 상황에 맞게 고려 ㅇ 막 개발해서 본인만 이해하게 만들면 안됨 ㅇ 성공한 비슷한 사례에 쓰인 코드를 그냥 복붙은 하는 것은 위험 ㅇ 문제를 해결 해야 될 시 해결했던 유사 사례가 있으면 재사용 -> 시간 낭비 방지 ㅇ 너무 많은 사람이 설계하지 않기. 더 복잡해지고 꼬임

커맨드와 템플릿 디자인 패턴과 마찬가지로 행위 패턴의 한 종류 객체의 역할에 중점을 두며, 객체는 내부 상태에 따라 여러 행위를 캡슐화 함 너무 많은 ConcreteState의 (기능) class 들이 생겨나면 context (컴퓨터) 가 과부화됨 1. 예제 1) 2. 예제 2) 3. 사용 예제 : 컴퓨터 작동

말 그대로 두 개이상의 패턴을 합쳐 문제를 해결 (MVC 패턴은 가장 많이 쓰이는 컴파운드 패턴 중 하나) MVC란 model (비즈니스 로직), view (시각) , controller (요청 처리) 합성어 model : 비즈니스 로직은 정보 저장 및 쿼리 처리 (CRUD 작업) view는 사람들이 보는 홈페이지 같은 것 controller는 model과 view의 요청을 처리 MVC 패턴을 사용하면 유지보수가 쉽다 백앤드 로직을 건드리지 않고 독립적으로 프론트앤드를 수정 가능 1. 예제 1) 2. 예제 2)

템플릿 메소드 디자인 패턴은 코드의 중복을 최소화 여러 알고리즘의 클래스가 비슷하거나 같은 로직을 구현할 때 활용 서브클래스를 오버라이드해 여러 알고리즘을 구현할 수 있는 경우 사용 예를 들면 커피를 끓이는 순서와 차를 끓이는 순서는 흡사하다고 볼 수 있음. 모든 iOS 기기에서 사용할 수 있는 크로스 컴파일러를 만들 때 템플릿 메소드 패턴이 적합 단점으로는 디버깅이 어렵고 필요없는 메소드를 구성할 수 도 있다. 유지보수가 까다롭다. 1. 예시 1) 2. 예시 2) 2. 사용 사례 : 여행사

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

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