스택큐힙리스트

왜 필요한가?업무 로직이 복잡해질수록 if (status == CREATED) … else if (status == SHIPPED)… 같은 분기문이 폭발한다. 새 상태가 추가될 때마다 코드가 누더기가 되는 건 시간문제다. State 패턴은 객체의 상태를 클래스로 쪼개고, 상태별 동작(행위)을 그 클래스 안에 숨겨 버린다. 그러면 Context(주 객체)는 “지금 내가 어떤 상태인가?”만 알고 있으면 된다. 조건문 대신 상태 객체 교체만으로 행동이 바뀌니, 가독성과 유지보수성이 크게 올라간다.핵심 개념 한 줄 요약“상태를 클래스로 캡슐화해, 객체의 행동을 런타임에 교체한다.”Context ↔ State 인터페이스 ↔ ConcreteState 들이 만드는 삼각 구도가 전부다.Kotlin 예제 — 주문 상태 ..

왜 WebSocket + STOMP인가?채팅·알림처럼 양방향 저지연이 필수인 기능은 HTTP Polling이나 SSE만으로 한계가 있습니다. WebSocket으로 영구 연결을 열고, STOMP 프로토콜로 채널·헤더·구독 개념을 입혀주면 메시지 라우팅이 쉬워집니다. Spring Boot는 spring-websocket 모듈 하나로 이 조합을 깔끔히 지원해 왔고, 2025년 현재 Boot 3.3에서도 설정이 거의 변하지 않았습니다.1️⃣ 의존성 한 줄implementation("org.springframework.boot:spring-boot-starter-websocket")외부 브로커(RabbitMQ, Redis Streams 등)를 쓰려면 대응 스타터를 추가하세요.2️⃣ WebSocket 설정 클래스@..

1. ‘실시간’이 필요할 때 두 갈래 길알림·라이브 피드·채팅 같은 기능을 붙이다 보면 “Server-Sent Events(SSE)로 갈까, WebSocket으로 갈까” 갈등이 온다. 두 프로토콜은 모두 HTTP 위에서 동작하지만 성격이 확연히 다르다. 오늘 글에서는 “상황별 최적 선택법”을 정리한다.2. SSE — 단방향 스트리밍, 가볍고 자동 복구까지단방향: 서버→클라이언트 전용. 클라이언트가 뭘 보낼 일 없는 뉴스·주가·알림에 최적이다.HTTP 그대로: 별도 업그레이드 없이 text/event-stream으로 열려서 프록시·로드밸런서 호환성이 높다.자동 재접속 + 체크포인트: 브라우저 EventSource가 끊기면 재연결하고, Last-Event-ID로 놓친 메시지를 이어받는다.가벼운 서버 구현: ..

변화가 생기면 알아서 퍼지게 하자! 이벤트 버스·알림 시스템의 기본 뼈대 Observer가 뭐길래?Observer(옵저버) 패턴은 “관찰 대상(Subject)”과 “구독자(Observer)” 사이에 느슨한 연결을 만들어,대상에게 변화가 생길 때마다 구독자에게 자동으로 알림을 뿌려 주는 행위(Behavioral) 패턴입니다.쉽게 말해 “뉴스레터 발송” 구조와 똑같습니다 — 발행인이 기사(상태)를 갱신하면, 구독자 메일함(반응)이 자동으로 울리니까요.언제 유용할까?이벤트 버스: Spring ApplicationEventPublisher처럼 서비스 곳곳에서 발생한 도메인 이벤트를 한 줄로 발행 → 여러 리스너가 동시에 처리UI 데이터 바인딩: Jetpack Compose·SwiftUI 같은 선언형 UI가 상태..