책임 떠넘기기란 말 그대로 각 객체가 본인이 처리하지 못하는 업무를 다른 객체에게 처리할 것을 떠넘기는 것을 의미한다.Express로 만든 API 서버에서 어떤 요청이 들어왔을 때 해당 요청을 어느 엔드포인트에서 처리할지 적합한 처리 주체를 만날때까지 미들웨어와 라우터

GithubAction으로 AWS에 배포할 때 GithubAction 인스턴스 상에서 AWS 설정을 해야한다. 이때, 필요한 권한을 받은 유저의 access key와 secret access key를 필요로하는데, 최소한의 권한 설정을 했어도Github 같은 서드파티

어떤 데이터의 구조를 나타내는 객체가 있고 이 객체로 수행하는 처리작업을 별도의 객체로 분리할 때 사용할 수 있는 것이 Visitor 패턴이다. 즉, 데이터의 구조와 처리를 분리하는 패턴이다.예를들어, 어떤 사각형을 나타내는 객체 Square가 있고 이 객체는, 사각형

우선, GoF에서 이야기하는 디자인 패턴으로서의 Decorator는 Java, Python, Typescript 등의 언어에 등장하는 Decorator@라는 기능과는 별개의 개념이다. 둘 다 상위 컨텐츠가 하위 컨텐츠를 감싸고 부가적인 기능을 제공하기에 같은 이름이 사

Composite이란 사전적으로 혼합물이라는 뜻이다. 언뜻 다른 패턴들과는 다르게 이름만으로 직관적으로 그 역할을 유추하기가 다소 쉽지는 않지만, 이름 그대로 서로 다른 무엇인가를 혼합하여 하나인것처럼 취급하는 패턴이다. 보통 내용물과 그릇, 혹은 단수와 복수를 하나로

Strategy는 전략이며, 소프트웨어에서의 전략은 특정 기능을 어떤식으로 구현할지에 대한 알고리즘 혹은 비즈니스 로직이다.Strategy 패턴은 하나의 목적을 가지는 여러개의 전략이 있을 때 이를 효과적으로 관리하고 또 교체하여 사용하기 편리하게 하기 위해 사용한다.

앞서서 이미 Factory Method라는 디자인 패턴에 대해서 다루었었다. 인스턴스를 생성해내는 추상적인 객체를 만들어두고, 구체적으로 어떤 인스턴스를 어떻게 만들지는 하위에서 구체적인 객체를 작성하면서 결정하는 디자인 패턴이었다.Abstract Factory도 유사

pnpm으로 모노레포 프로젝트를 사용하다보면 심심치 않게 등장하는 에러다.원인은 간단하다,의존성을 평면적으로 설치하여 관리하는 npm이나 yarn과는 다르게, pnpm은 간접적인 의존성, 즉 X라는 의존성을 설치했을 때 X가 의존하는 Y들은 .pnpm이라는 경로 아래에

Bridge 패턴은 기능의 클래스 계층과 구현의 클래스 계층을 연결하는 역할을 한다. 따라서, 브릿지 패턴을 이해하기 위해서는 먼저 클래스 계층이 어떻게 구분되는지를 먼저 이해해야한다.어떤 기능을 구현한 클래스 Something이 있다고 가정하자. 이때 Somethin

Builder란 복잡한 객체를 만들 때 마치 건물처럼 각 프로퍼티를 하나하나 순서대로 쌓아가면서 객체를 완성해나가는 디자인 패턴의 일종이다. 여기서 "복잡한 객체"라는 말이 굉장히 추상적인데, 이는 그만큼 Builder 패턴이 쓰이는 경우가 다양하기 때문이다.Build

Prototype이란? Prototype 패턴은 이름에서 나타나는 것처럼 어떤 인스턴스의 원형을 정하는 패턴이다. 클래스를 인스턴스화하고 내부 구조를 만드는 과정이 복잡할 때, 이를 매번 새로 인스턴스화하고 만드는 것은 비효율적이다. 이럴 때, 프로토타입 패턴에 따

클래스는 new 키워드를 사용하여 인스턴스화 시킬 수 있으며, new를 사용할때마다 말 그대로 새로운 인스턴스를 생성한다. 하지만 경우에 따라서 인스턴스를 단 하나만 생성하여 재사용 하고 싶은 때도 있다.예를들어, 클래스 안에 프로그램 내 여러 곳에서 공용으로 접근하는

앞선 장에서 살펴봤던 Template Method를 인스턴스를 생성할 때 적용한 패턴이 Factory Method이다.Factory Method에서는 인스턴스 생성 방법을 상위 클래스에서, 즉 Template Method를 통해 결정하되, 구체적으로 어떻게 생성할지는

어떤 모양이나 형식과 같은 틀만 정해져있고 어떻게가 비어있는 것을 템플릿이라고 한다. 그리고 Template Method는 이름 그대로 템플릿이 되는 메소드를 추상 메소드Abstract Method를 사용해 뼈대만 만들고 하위 클래스에서 구현방식을 직접 정의하는 패턴이

현실에서 전가기기들의 어댑터가, 콘센트에서 제공되는 전류와 전압을 사용하려는 전가기기가 지원하는 규격에 맞게 바꿔주는 것처럼 Adapter란 주어진 객체를 필요한 상황에 맞게 바꾸는 패턴이다.Adapter 패턴은 Wrapper 패턴이라고도 불리며, 기존의 객체를 포장하

항해플러스 7주간의 첫 프로젝트가 끝났다.프로젝트라는 말을 붙이기에는 다소 초라한 결과물이기는하지만, 그래도 TDD를 토대로 시나리오를 설계하고 코드를 구현했고, CI/CD를 파이프라인을 통해 main 브랜치의 품질 유지와 자동배포를, 그리고 통합 모니터링 시스템을 구

Iterator란? 반복문을 사용해서 개발자가 직접 인덱스를 통해 각각의 원소를 꺼내오는 대신, 자동으로 모든 원소를 차례대로 꺼내서 작업을 연속적으로 할 수 있게 해주는 행동 패턴(Behavioral Pattern)의 일종. 왜 쓸까? 반복로직을 구

C++ 컴파일러 경로 설정이 잘 되어 있음에도 Nodejs C++ 애드온을 만들려고 관련 헤더를 임포트해보면 위와 같은 경로 에러가 발생했다.컴파일러 경로 자체가 문제가 아니다. 해당 헤더들이 설치된 위치가 C++ 컴파일러가 기본적으로 참조하고 있는 헤더들 위치와 다

그동안 구축한 서비스 아키텍쳐와 모니터링 시스템을 테스트하는 주간이었다. 그동안 게을러서 완성을 하지 못한만큼 테스트도 까다로웠다. 배달시스템의 대부분의 기능들이 api 엔드포인트는 물론이고 로직도 정상적으로 작동하지 않고 있었고, 또, 데이터베이스 시딩도 그냥

Nestjs는 자동으로 alias path를 사용하는데 이때 프로젝트에 따라 위 에러처럼 작동하지 않을때가 있다.여러 해법들이 있지만 module-alias 라이브러리를 사용하는 것이 가장 간단한 해법인 것 같다.적당히 원하는 위치에 아래의 파일을 작성하자.여기서 DI