[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #32] 빌더(Builder) 패턴: 상속 없이 단계적 객체 생성을 함수 합성으로 구현하기

이전 글에서는 추상 팩토리(Abstract Factory) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이도 Concepts, 람다, std::expected, coroutine, Ranges, std::format 등을 활용해 다양한 제품군 생성 로직을 유연하게 구현할 수 있음을 확인했습니다. 이번에는 생성(Creational) 패턴 중 빌더(Builder) 패턴을 다룹니다.빌더 패턴은 복잡한 객체를 단계별로 생성하기 위한 패턴으로, 전통적으로는 Builder 인터페이스와 구체 빌더, 그리고 Director 클래스를 통해 생성 과정과 제품 구성을 분리했습니다. 그러나 이는 클래스 증가, 유지보수 어려움, 에러 처리나 비동기 처리, 조건부 단계 추가 등 다양한 요구사항에 대응하기 어렵습니다.C++20..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #31] 추상 팩토리(Abstract Factory) 패턴: Concepts와 람다로 객체 패밀리 생성 유연하게 하기

이전 글에서는 전략(Strategy) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이도 람다와 Concepts, std::expected, coroutine, Ranges, std::format 등을 활용해 알고리즘(전략)을 런타임에 교체 가능하게 하고, 비동기 처리나 로깅, 조건부 선택 등 다양한 상황에 쉽게 대응할 수 있음을 확인했습니다. 이번에는 Creational(생성) 패턴 중 하나인 추상 팩토리(Abstract Factory) 패턴을 다룹니다.추상 팩토리 패턴은 관련된 여러 객체(제품)들을 묶어 "제품군(family)"을 생성하는 인터페이스를 제공하는 패턴입니다. 전통적으로는 AbstractFactory 인터페이스와 구체 팩토리 클래스를 상속으로 정의하고, 각 제품(객체) 생성 메서드를 오..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #30] 전략(Strategy) 패턴: 람다와 Concepts로 알고리즘 동적 선택하기

이전 글에서는 상태(State) 패턴을 모던 C++ 관점에서 재해석하며, std::variant, std::visit, Concepts, std::expected, coroutine, Ranges, std::format 등을 활용해 상속 없이 값 기반 상태 머신을 구현하고, 조건부 전이, Undo/Redo, 비동기 처리, 로깅 등 다양한 요구사항에도 대응할 수 있음을 확인했습니다. 이제는 행동(Behavioral) 패턴 중 전략(Strategy) 패턴을 다룹니다.전략 패턴은 알고리즘 패밀리를 정의하고, 이를 교체 가능하게 하여 런타임에 다른 알고리즘을 선택할 수 있도록 하는 패턴입니다. 전통적으로는 Strategy 인터페이스와 ConcreteStrategy 클래스를 상속해 구현했지만, 이는 알고리즘 추가..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #29] 상태(State) 패턴: std::variant와 Concepts로 선언적 상태 머신 구현하기

이전 글에서는 책임 연쇄(Chain of Responsibility) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이 람다와 함수 합성, std::expected, coroutine, Ranges, std::format 등을 활용해 요청 처리 파이프라인을 단순하고 유연하게 구현할 수 있음을 확인했습니다. 이제는 행동(Behavioral) 패턴 중 상태(State) 패턴을 다룹니다.상태 패턴은 객체가 내부 상태에 따라 서로 다른 행동을 수행하도록 하는 패턴입니다. 전통적으로는 State 인터페이스, ConcreteState 클래스를 상속해 상태별로 다른 메서드를 오버라이드하고, 상태 전이 시 상태 객체 교체 방식으로 구현했습니다. 이는 새로운 상태 추가 시 클래스 증가, 상태 전이 로직 분산, 유지보수..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #28] 책임 연쇄(Chain of Responsibility) 패턴: 함수 파이프라인으로 요청 처리 흐름을 간결히 구현하기

이전 글까지 우리는 대부분의 GoF 패턴을 모던 C++ 관점에서 재해석해왔습니다. 이번에는 행동(Behavioral) 패턴 중 아직 다루지 않은 책임 연쇄(Chain of Responsibility) 패턴에 주목합니다.책임 연쇄 패턴은 한 요청이 처리될 수 있는 핸들러를 체인 형태로 연결하고, 요청이 들어오면 체인을 따라가며 처리 가능 한 핸들러를 찾는 구조를 만듭니다. 전통적으로는 핸들러 인터페이스와, setNextHandler() 메서드를 통해 다음 핸들러를 연결하는 구조를 취했지만, 이는 상속 기반 설계로 인한 클래스 증가와 유지보수 어려움을 야기합니다.C++20 이상에서는 Concepts로 요청/응답 인터페이스를 제약하고, 람다와 함수 합성으로 핸들러를 정의해 상속 없이 체인을 구성할 수 있습니다..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[모던 C++로 다시 쓰는 GoF 디자인 패턴 총정리 #27] 프록시(Proxy) 패턴: 상속 없이 람다와 Concepts로 대리 객체 구현하기

이전 글에서는 플라이웨이트(Flyweight) 패턴을 모던 C++ 관점에서 재해석하며, 상속 없이 값 기반 공유 로직을 단순히 구현하고, 조건부 처리, 비동기 로딩, 로깅, 에러 처리 등 다양한 요구에도 쉽게 대응할 수 있음을 확인했습니다. 이번에는 구조적 패턴 중 프록시(Proxy) 패턴을 다룹니다.프록시 패턴은 객체 접근을 제어하거나, 지연 로딩(Lazy Loading), 원격 호출(Remote Proxy), 캐싱(Caching), 권한 체크 등의 기능을 대리 객체를 통해 투명하게 추가하는 패턴입니다. 전통적으로는 상속 기반 인터페이스와 Proxy 클래스를 정의해 접근 로직을 구현했으나, 이는 클래스 증가, 유지보수 어려움, 에러 처리나 비동기 처리 시 복잡성을 초래합니다.C++20 이상에서는 Con..

• format_list_bulleted 개발 이야기/C++
• · 2024. 12. 16.
• textsms

[개발자 영어] Brownfield vs Greenfield

이번에 소개할 표현은 "Brownfield vs Greenfield"라는 대비 개념입니다. 소프트웨어 개발에서 "Greenfield Project"는 아무런 제약 없이 백지 상태에서 시작하는 프로젝트를 의미하고, 반대로 "Brownfield Project"는 이미 구축된 레거시 코드나 인프라를 개선하거나 확장하는 상황을 가리킵니다.1. 의미"Greenfield"는 새로운 땅에 건물을 올리듯, 아무것도 없는 상태에서 시작하므로 최신 기술과 아키텍처를 자유롭게 적용할 수 있습니다. 이로 인해 기술 부채 없이 깨끗한 코드를 작성하고, 최적의 디자인 패턴을 채택하기가 상대적으로 쉽습니다. 반면, "Brownfield"는 이미 존재하는 시스템을 다듬고 현대화하는 과정으로, 레거시 코드 이해, 기술 부채 해결, 기..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 16.
• textsms

[개발자 영어] Release Candidate (RC)

이번에 소개할 표현은 "Release Candidate (RC)"입니다. "Release Candidate"는 새로운 소프트웨어 버전이 공식 릴리즈 직전에 있는 상태로, 최종 검증을 위해 내놓은 거의 최종 형태의 빌드를 의미합니다. 즉, 이 빌드가 큰 문제 없이 검증을 통과한다면 그대로 정식 릴리즈 버전으로 이어지며, 만약 문제가 발견된다면 수정 후 다시 RC를 내거나 일정을 조정하게 됩니다.1. 의미"Release Candidate"는 개발팀이 '이제 거의 다 됐다'고 판단했지만, 그래도 마지막으로 사소한 버그나 마감 전 확인이 필요한 상태를 가리킵니다. RC 버전은 종종 테스트 그룹이나 제한된 사용자에게 배포되어 실제 서비스 환경과 유사한 조건에서 시험을 받거나, 사내 QA 팀의 철저한 검증을 거쳐,..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 16.
• textsms

[개발자 영어] Epic

이번에 소개할 표현은 "Epic"입니다. "Epic"는 소프트웨어 개발에서 하나의 큰 비즈니스 목표나 기능을 포괄하는 광범위하고 장기적인 요구사항을 의미합니다. 즉, 단일 스프린트나 짧은 주기 안에 모두 구현하기 어려울 만큼 크고 복잡한 기능 덩어리로 볼 수 있습니다. 에픽(Epic)은 나중에 더 작은 단위의 User Story나 작업(Task)으로 분할되어, 점진적이고 애자일하게 개발될 수 있습니다.1. 의미"Epic"는 단기간에 완성하기 어려운 대형 요구사항 뭉치를 가리키며, 이를 관리하기 위해서는 세분화와 우선순위 재조정이 필요합니다. 에픽은 제품 로드맵에 반영되는 전략적 목표나 큰 기능 영역에 해당하며, 여러 User Story를 모두 완료해야 에픽 하나를 완성할 수 있습니다.예:"이번 분기 목표..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 16.
• textsms

[개발자 영어] Scope Creep

이번에 소개할 표현은 "Scope Creep"입니다. "Scope Creep"는 프로젝트 진행 중 요구사항이나 기능 범위가 통제 없이 계속 확대되어, 초기 계획보다 훨씬 커지고 복잡해지는 현상을 의미합니다. 즉, 처음에는 명확하고 제한된 목표로 시작했으나, 진행 도중 이해관계자의 추가 요청, 불명확한 요구사항 관리 등으로 인해 범위가 점점 커져서 일정 지연, 품질 저하, 비용 증가 등의 문제를 초래하게 됩니다.1. 의미"Scope Creep"는 '프로젝트 범위(Scope)'가 시간이 지날수록 서서히(creep) 늘어나는 상황을 가리킵니다. 이는 명확한 요구사항 관리와 우선순위 설정이 부족할 때 자주 발생하며, 개발팀은 예측 불가능한 추가 작업으로 인해 생산성이 떨어지고, 프로젝트 전체 일정 관리가 어려워..

• format_list_bulleted 미국 빅테크/일일 영어
• · 2024. 12. 16.
• textsms