https://wid-blog.github.io/posts/tech/design-pattern/Recent content in 디자인 패턴 on wid's blogHugokoSat, 15 Feb 2025 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/circuit-breaker/Sat, 15 Feb 2025 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/circuit-breaker/Circuit Breaker 의 차단 트리거와 회복 전략은 함께 설계되어야 한다. 회복 없는 차단은 의존성을 영구히 끊고, 차단 기준 없는 회복은 무의미한 cycling 이다.https://wid-blog.github.io/posts/tech/design-pattern/rate-limiting/Fri, 14 Feb 2025 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/rate-limiting/Rate Limit 알고리즘을 고르기 전에, 어느 계층에서 보호할지가 먼저 알고리즘의 선택지를 좌우한다. L4/L7/Application 계층과 Token/Leaky/Sliding/Fixed 알고리즘의 교차 관계를 정리한다.https://wid-blog.github.io/posts/tech/design-pattern/builder/Sun, 11 Feb 2024 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/builder/Builder 는 생성자의 세 가지 한계가 동시에 모일 때의 해결책이다. 매개변수 수가 많고, 일부가 선택적이고, 단계적 검증이 필요한 경우. 셋이 같이 모이지 않으면 다른 도구로 충분하다. 언어가 named/default 매개변수를 제공하면 Builder 의 필요도 자연스럽게 줄어든다.https://wid-blog.github.io/posts/tech/design-pattern/factory/Sun, 04 Feb 2024 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/factory/Factory 의 공통 의도는 객체 생성과 사용의 분리다. 세 변형 (Factory Method / Abstract Factory / Static Factory Method) 은 분리 방식이 다르고 적합한 상황도 다르다. 실무에서는 Static Factory Method 가 가장 자주 쓰이고, DI 컨테이너가 등장하면 명시적 Factory 의 일부 역할이 컨테이너로 흡수된다.https://wid-blog.github.io/posts/tech/design-pattern/singleton/Sun, 28 Jan 2024 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/singleton/Singleton 은 가장 단순한 패턴이지만 안티패턴 논란의 대표 사례다. 단일 인스턴스 보장과 전역 접근을 한 패턴에 묶은 결정이 강한 결합과 테스트 어려움의 원인. DI 가 두 의도를 분리한 일반 대안이다.https://wid-blog.github.io/posts/tech/design-pattern/dependency-injection/Thu, 25 Jan 2024 00:00:00 +0000https://wid-blog.github.io/posts/tech/design-pattern/dependency-injection/DIP(원칙), IoC(패턴), DI(기법)는 서로 다른 추상 수준에 있는 개념이다. 위계를 분명히 봐야 프레임워크 기능과 설계 원리가 섞이지 않는다.