[Design Pattern] 커맨드 패턴 (Command Pattern)
·
Design Pattern
1. 커맨드 패턴커맨드 패턴은 명령을 추상화해서 객체로 다루는 것을 말한다.명령을 객체로 다루게 되면 이를 소유한 객체는 명령을 실행할 수 있다.명령을 객체로 다루게 되면 큐에 명령들을 담아 원할 때 꺼내 명령을 실행할 수 있다. 2. 커맨드 패턴은 언제 사용할까?게임에서 캐릭터를 선택할 때마우스 클릭과 키보드 엔터로 캐릭터를 선택할 수 있다. 서로 다른 상호작용이 동일한 기능을 수행해야할 때하나의 커맨드 객체를 소유하여 이를 실행함으로써 코드를 재사용할 수 있도록 처리할 수 있다. 3. 커맨드 패턴 구조Invoker : 커맨드를 저장하고 실행하는 객체이다.Command : 커맨드 인터페이스Command1 : 커맨드 인터페이스를 상속받은 커맨드 클래스이다. 실행할 로직을 구현한다.Receiver : 커..
[Design Pattern] 퍼사드 패턴 (Facade)
·
Design Pattern
1. 퍼사드 패턴퍼사드 패턴은클라이언트가 여러 객체를 참조하여 기능을 처리하는 것이 아닌하나의 객체를 참조하여(퍼사드 객체) 기능을 처리하는 패턴을 의미힌다. 2. 퍼사드 패턴 필요한 이유클라이언트가 외출 시 여러 가지 작업을 해야한다고 가정해보자.가스밸브 잠금 확인전등/조명 꺼짐 확인에어컨/난방기 꺼짐 확인창문 닫힘 확인클라이언트는 여러 객체를 참조하여 이를 Check, Check, Check 하는 것이 아닌외출시 (LeaveHome) 이 모든 것을 확인해주는 스마트 홈 시스템 객체(퍼사드 객체)를 하나 만들고클라이언트는 하나의 객체를 참조하여 한 번의 호출로 모든 작업을 처리하도록 구현한다. 클라이언트는 여러 객체의 세부 함수들을 알지 않아도 되며퍼사드 객체를 통해 필요한 기능들을 모두 수행할 수 있..
[Design Pattern] 프록시 패턴 (Proxy Pattern)
·
Design Pattern
1. 프록시 패턴어떤 객체에 대한 접근 제어를 프록시 객체를 만들어 위임하는 패턴을 말한다. 프록시 객체는 원본 객체를 호출 전새로운 기능(동작, 접근 제어, 로깅, 캐싱)을 추가로 수행한다. 클라이언트는 프록시 객체를 원본처럼 사용한다. 2. 프록시 패턴 예시원본 객체에 "관리자 권한"이 필요한 경우프록시 객체를 만든 뒤 원본 객체와 컴포지션 관계를 만들고관리자 권한 기능(인증, 권한 확인)을 작성하여 원본 객체를 호출하기 전 처리될 수 있도록 구현한다.#include #include #include // 인터페이스 (Subject)class IAdminService{public: virtual void PerformSensitiveOperation() = 0; virtual ~IAdminS..
[Design Pattern] 어댑터 패턴 (Adapter Pattern)
·
Design Pattern
1. 어댑터 패턴어댑터 패턴은기존 시스템에서 새로운 라이브러리를 추가할 때호환될 수 있도록 중간 레이어 클래스를 만드는 작업을 말한다. 2. 어댑터 패턴 예제상황 1SortingMachine 클래스는 ISortEngine 인터페이스를 의존하여 A_SortEngine을 사용해 왔다.그러다 성능 문제로 인하여 타 회사(B)의 엔진으로 교체 결정을 하게 되었다. 상황 2타 회사(B)로부터 전달받은 B_SortEngine을 가져왔으나 기존 코드와 호환되지 않았다.기존 코드에서 작동되도록 B_SortEngine 코드를 수정해볼까 생각하였으나 이는 원본 코드를 훼손할 뿐더러 어느 정도의 시간이 걸릴지 예측할 수 없었다. 해결 방안기존의 코드에서 사용하는 ISortEngine 인터페이스를 구현한 중간 클래스를 만든다..
[Design Pattern] 팩토리 패턴 (Factory Pattern)
·
Design Pattern
1. 팩토리 패턴팩토리 패턴은 객체 생성 로직을 팩토리(인터페이스)로 캡슐화하여클라이언트 코드가 특정 구채 클래스에 직접 의존하지 않도록 하는 생성 디자인 패턴을 가리킨다. 2. 팩토리 패턴은 언제 사용할까?// 원본 코드Document doc = new WordDocument();// 수정할 코드Document doc = new PDFDocument();새로운 제품 클래스가 추가되어 기존 코드를 수정하고자 한다.프로젝트 모든 코드에서 WordDocument 클래스 대신 PDFDocument 클래스를 사용하고자 한다면일일이 찾아 관련 코드를 변경해줘야 한다. 기존 코드를 SOLID 원칙으로 바라본다면개방 폐쇄 원칙 - OCP (기존 코드를 수정하지 않고 확장이 가능해야 한다.)의존성 역전 원칙 - DIP..
[DesignPattern] 모던 객체지향 설계 - 활용 예시
·
Design Pattern
1. 스마트 포인터를 통한 안전한 메모리 관리전통적으로 C++에서는 new와 delete를 사용하여 동적 메모리를 관리했다.하지만 이는 메모리 누수와 댕글링 포인트 문제를 유발할 수 있다. 모던 C++에서는 스마트 포인터(std::shared_ptr)를 사용하여RAII 원칙을 적용해 이러한 문제를 해결하였다. 전통 방식class Resource { int* data;public: Resource() { data = new int[100]; // 동적 메모리 할당 std::cout 문제점delete를 잊는 경우에는 메모리 누수가 발생한다.예외 발생시 해제가 누락되어 리소스가 해제되지 않을 수 있다. 모던 방식#include #include class Resource { ..
[DesignPattern] 모던 객체지향 설계 - 추가 원칙
·
Design Pattern
1.  SOLID 원칙SRP (단일 책임 원칙)각 클래스는 하나의 책임만 갖도록 하는 원칙OCP (개방-폐쇄 원칙)어떠한 기능을 추가할 때 확장이 가능하지만 기존 코드가 수정되지 않아야 하는 원칙LSP (리스코프 치환 원칙) : 자식 클래스가 부모 클래스의 역할로 대체될 때에도 정삭적으로 동작하여야 하는 원칙 자식 클래스를 구현할 때 부모클래스가 수정되면 안된다.부모 클래스가 수정되면 다른 자식 클래스의 기능이 변경된다.ISP (인터페이스 분리 원칙)불필요한 메서드 의존성을 줄이기 위한 필요한 메서드만 의존할 수 있는 인터페이스를 설계한다.의존성이 높아지면 코드 수정이 힘들다.DIP (의존성 역전 원칙)구체적인 클래스가 아닌 인터페이스나 추상 클래스에 의존하는 원칙 ex) 오리1 = new 청둥 오리, ..