dh_0e

템플릿 메서드 패턴(Template Method Pattern)알고리즘의 구조(뼈대)를 상위 클래스에 정의하고, 알고리즘의 일부 단계는 서브클래스에서 구체적으로 구현할 수 있도록 하는 행동 패턴목적: 알고리즘의 구조를 유지한 채로 행동을 다르게 변경 가능필요한 상황ex) 회사 문서들을 분석하는 앱을 만들고 있다고 가정다양한 포맷(pdf, doc, csv) 문서에 대해 일괄된 형식으로 의미 있는 데이터 추출포맷에 맞게 처리하는 부분(알고리즘) 외에 많은 코드 중복(처리 과정)이 발생아이디어알고리즘을 일련의 단계들로 나누고 이러한 단계를 메서드로 변환단일 템플릿 메서드 내부에 단계 메서드들에 대한 일련의 호출로 구성상속을 통해 추상 단계 메서드를 오버라이드 해서 구현상위 클래스에서 추상적인 메서드 틀을 짜고..

중재자 패턴(Mediator Pattern)정의: 객체 간의 직접 통신을 제한하고 중재자 객체(mediator)를 통해서만 협력하도록 하는 행동 패턴중재자(Mediator): 객체 간의 통신을 관리하고 매개체 역할을 수행하여 객체 간의 결합을 낮추고 유연성을 확보필요 상황여러 객체들이 상호작용하는 복잡한 상황에서 각 객체가 서로를 참조하게 되어 한 클래스 수정 시 연관된 클래스들의 수정이 연쇄적으로 발생할 때 필요ex) 프로필 편집 대화 상자아이디어각 객체 간의 연결을 느슨하게 만들어야 함객체 간의 직접적인 통신은 중단하고, 이러한 호출을 대신 처리할 수 있는 중재제 객체를 두어서 간접적으로 협력시킴M:N의 관계를 M:1의 관계로 전환 구성 요소역할상세 설명1. Components중재자 참조를 통해 소통..

상태 패턴(State Pattern)객체의 내부 상태가 변경될 때, 객체 스스로가 상태에 따라 행동을 변경할 수 있도록 하는 행동 패턴상태(State): 객체가 가질 수 있는 어떤 조건이나 상황ex) TV의 상태 ON/OFF에 따라 음량 버튼의 동작 방식이 달라지는 경우필요한 상황만약 문서(Document) 클래스가 Draft(초안), Moderation(검토), Published(출판됨)와 같은 여러 상태를 가지고 publish 메서드가 각 상태에 따라 다르게 작동해야 할 때publish 메서드Draft(초안): 문서를 Moderation(검토) 상태로 이동Moderation(검토): 문서를 공개하거나 관리자에게만 공개Published(출판됨): 아무런 작업을 하지 않음상태 패턴 아이디어객체의 모든 가..

해석자 패턴(Interpreter Pattern)언어(language)의 문법 규칙을 표현하고 해당 언어의 문법 규칙(grammar rules)을 클래스로 표현하고, 이 클래스들을 조합하여 해당 언어의 문장을 해석하는 데 사용되는 행동 패턴주요 용도: 컴파일러 또는 인터프리터를 개발할 때 언어의 문법 구조를 나타내는 데 유용함특징: 새로운 언어를 추가하거나 기존문법을 변경할 때 유연하게 확장 가능ex) 정규 표현식, 후위 표기법 Posfix Expression(후위 표기법) 예제구분Infix Notation (중위 표기법)Postfix Notation (후위 표기법)특징사람들이 보기에 익숙함사람이 보기에 직관적이지 않지만, 계산이 쉬움괄호/우선순위연산자 우선순위 때문에 괄호가 필요함 (처리 복잡)수식에 ..

Behavior Design Patterns(행동 패턴)한 객체가 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배할지, 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔 패턴 책임 연쇄 패턴(Chain of Responsibility Pattern)클라이언트의 요청에 대한 세세한 처리를 한 객체가 전부 하는 것이 아닌,여러 개의 처리 객체들로 나누고 이들을 사슬(chain)처럼 연결해 연쇄적으로 처리하는 행동 패턴Handler(핸들러): 처리 객체를 지칭요청을 받으면 각 핸들러는 요청을 처리할 수 있는지 판단하고, 없으면 다음 핸들러로 책임을 전가필요한 상황온라인 주문 시스템을 개발하려고 하는 예시에서,인증된 사용자들만 주문을 생성할 수 있도록 시스템에 대한 접근을 제한관리 권한이 있..

Facade Pattern(퍼사드 패턴)라이브러리(or 서브시스템)에 대해 사용하기 간편한 인터페이스를 구성하기 위한 구조 패턴라이브러리의 각 클래스와 메서드의 사용이 복잡하거나 바로 가져다 쓰기에는 어려울 때, 퍼사드 패턴으로 디테일은 내부로 묶고 사용자가 쓰기 쉽게 정리하는 것Facade: 건물의 정면내부는 숨기고 외관만 보여주는 것에 비유(외관만 보고 전체를 이해)필요한 상황: 라이브러리의 여러 API를 조합해서 쓰는 상황에서 클라이언트의 코드의 라이브러리 의존성이 높을 때 Facade Pattern 구조Facade: 클라이언트가 편리하게 사용할 수 있도록 서브시스템의 기능 조합을 모아둠Subsystem Classes: 실제 복잡한 기능을 수행하는 클래스들Client: 서브시스템 객체를 직접 호..

Composite Pattern(복합체 패턴)전체-부분 관계의 트리 구조로 표현되는 객체들을 단일 객체(Interface)처럼 취급할 수 있게 해주는 구조 패턴단일 객체(Leaf)와 복합 객체(Composite)를 동일한 인터페이스를 사용하여 처리Leaf는 하위 요소가 없는 단일 객체를 의미하며, Composite는 Leaf나 다른 Composite 객체들을 포함하는 복합 객체 Composite Pattern 필요 상황 예시주문 시스템에서 여러 상품을 담은 상자의 가격을 계산하려고 할 때한 box에 여러 product와 작은 box들을 담을수 있음작은 box들도 여러 product를 담을 수 있음Origin: 상자의 가격을 계산하기 위해서는 내부 제품을 모두 살펴보면서 가격을 합산해야 함트리 전체 순회를..

구조 디자인 패턴(Structural Design Patterns)클래스들과 객체들을 더 큰 구조로 조립하여 구조를 유연하고 효율적으로 유지하도록 돕는 패턴 Adapater Pattern호환성이 없는 인터페이스를 가진 클래스들을 더 큰 구조로 조립하여 구조를 유연하고 효율적으로 유지하도록 돕는 패턴이미 구축되어 있는 것을 새로운 어떤 것에 사용하려고 할 때 양 쪽 간의 호환성을 유지해주기 위해 사용ex) 주식 시장 모니터링 앱을 만드는데 여러 소스에서 주식 데이터를 XML 형식으로 다운로드 해서 보여준다고 가정 어느 시점에 타사의 스마트 분석 라이브러리를 통합하여 개선하려고 했는데 이 라이브러리가 JSON 형식으로 입력 요구특징코드 유지: 기존 시스템의 코드를 수정하지 않고 재사용성을 높임호환성..

Abstract Factory Pattern (추상 팩토리 패턴)연관 있는 여러 객체(제품) 군(family)의 생성을 추상화한 생성 패턴팩토리 메서드 패턴이 단일 객체 생성을 추상화하는 반면, 추상 팩토리 패턴은 관련 있는 여러 객체(제품)들의 일관된 생성을 추상화함ex) {Chair, Sofa, CoffeeTable}에 대해 스타일 별로 각 제품을 일관되게 생성해야 함새로운 스타일의 제품 군이 추가되더라도 기존 코드를 변경하지 않고 추가할 수 있어야 합니다.제품별로 인터페이스를 추상화하고, 모든 추상 제품에 대한 생성 메서드를 가지는 팩토리로 추상화합니다.각 서브 팩토리에서는 스타일에 일관된 제품군이 생성될 수 있도록 생성 메서드를 구현합니다. ex) Window와 Mac OS의 Cross-platf..

팩토리 메서드 패턴(Factory Method Pattern)객체 생성을 서브 클래스에 위임하는 생성(Creational) 패턴생성 패턴: 객체 생성 메커니즘을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램 구조에 큰 영향을 주지 않도록 유연성을 제공하는 패턴객체를 생성하기 위한 인터페이스는 상위 클래스에서 정의되지만, 실제로 어떤 클래스의 인스턴스를 생성할지는 서브 클래스가 결정함사용 상황 객체의 생성을 코드의 나머지 부분으로부터 분리하려고 할 때사용자가 자체 객체를 만들어 시스템을 확장하는 방법을 제공하고자 할 때객체 생성에 있어서 기존의 코드를 건들지 않고 쉽게 확장할 수 있는 방법이 필요할 때 (OCP: 개방-폐쇄 원칙)ex) ↓ 배를 만드는 공장(ShipFactory)에서 client의 요청에..

디자인 패턴SW를 설계할 때, 틀정 맥락/상황에서 자주 발생하는 문제들의 해결 방법을 반복적으로 재사용할 수 있도록 패턴화한 것다양한 설계 분야에서도 디자인 패턴의 개념이 사용됨건출 분야에서 디자인 패턴에 대한 논의가 처음으로 시작됨 디자인 패턴의 역사1987년, Ward Cunningham과 Kent Beck: Christopher Alexander의 패턴 아이디어를 객체 지향 설계로 확장하고 Smalltalk 언어 기반으로 패턴을 설명1987년, Erich Gamma: "important of patterns and how to capture them" 주제로 학위 논문을 출간1992년, Jim Coplien: C++ 언어 기반의 패턴을 설명한 "Advanced C++ Programming Style..

SOLID 설계 원칙SRP - 단일 책임 원칙OCP - 개방-폐쇄 원칙LSP - 리스코프 치환 원칙ISP - 인터페이스 분리 원칙DIP - 의존성 역전 원칙객체 지향 SW를 견고하고 확장 가능하게 설계하기 위한 다섯 가지 기본 원칙Robert C. Martin에 의해 명명된 설계의 기본 원칙효과유지보수 용이성 증가불필요한 복잡성 제거생산성 향상디자인 패턴(design pattern)은 SOLID 원칙에 기반하여 만들어짐디자인 패턴: SW 설계 과정에서 자주 등장하는 문제의 솔루션을 재사용할 수 있도록 패턴화 한 것 SRP(Single Responsibility Principle): 단일 책임 원칙모든 클래스는 단 하나의 책임(responsibility= 객체가 해야 하는 일)만을 가져야 함즉 하나의 클래..