스택큐힙리스트

1. 테스트 시나리오실무에서 많이 쓰는 수수료 계산 전략을 세 가지 버전으로 만들고 JMH 1.37(kotlinx-benchmark 래퍼)로 5 회 warm-up, 10 회 measurement를 돌렸다.인터페이스 + 클래식 구현함수 타입((Int) -> Int) 전달inline 고차함수 – inline fun pay(amount: Int, fee: (Int) -> Int)모두 동일한 곱셈·나눗셈 로직, JVM 21, -Xms2g -Xmx2g, M2 Max.2. 결과 요약 (평균 값·allocation 수)인터페이스 호출: ≈ 80 ns/op, 할당 0함수 타입(비-inline): ≈ 130 ns/op, 1 객체 ≈ 24 Binline 고차함수: ≈ 13 ns/op, 할당 0핵심 포인트는 두 가지다.람다..

“수수료 정책 또 바뀌었대…”클래스 만들기 귀찮다면 코틀린 고차함수로 전략을 바로 끼워 넣자. 인터페이스도, DI 설정도 필요 없다. 함수 하나가 곧 전략 객체가 된다.typealias FeePolicy = (Int) -> Int // ① 전략 타입fun pay(amount: Int, strategy: FeePolicy) = amount + strategy(amount) // ② 컨텍스트println(pay(10_000) { (it * 3) / 100 }) // ③ 런타임 전략 주입1줄: typealias로 전략(알고리즘) 시그니처 선언2줄: pay 함수가 컨텍스트 역할, 전략에 계산 위임3줄: 호출부에서 람다만 넘기면 카드·계좌이체·쿠폰 어떤..

“클래스가 바뀌어야 할 이유는 단 하나여야 한다.” 이 단순한 문장이 지켜지지 않을 때 나타나는 것이 바로 거대 클래스, if‒else 난무, UnsupportedOperationException 남발 같은 대표적인 코드 냄새입니다. 국내 개발자들이 많이 찾은 SRP(단일 책임 원칙) 리팩터링 후기들을 종합해, 실무에서 바로 써먹을 7단계 체크리스트를 정리했습니다. 1. 코드 냄새 스캐닝new 나 if(type)가 몰려 있는 거대 메서드한 클래스에 DB + 네트워크 + 뷰 로직이 섞여 있는 경우인터페이스 구현체가 사용하지 않는 메서드에 예외를 던질 때2. 책임 라벨링클래스·메서드마다 “이 로직은 누구를 위해 존재하나?” 메모를 붙여보세요.라벨이 두 개 이상이면 SRP 위반 후보입니다.3. 행위·데이터 분..

“고수준 모듈이 저수준 모듈에 끌려다니지 않게 해라.”― 의존 역전 원칙(Dependency Inversion Principle)SOLID의 마지막 퍼즐, DIP는 “설계 방향을 아래에서 위로 뒤집는” 순간 코드를 한층 유연하게 만듭니다. 국내 인기 블로그에서도 스프링·안드로이드 예제로 꾸준히 조회 수를 올리는 이유가 바로 여기에 있죠.1. DIP란 무엇인가?정의:고수준 모듈(비즈니스 규칙)은 저수준 모듈(구현 세부)과 직접 의존하지 않는다.양쪽 모두 추상화(인터페이스·추상 클래스) 에 의존해야 한다.추상화는 구체화에 의존해서는 안 된다.한마디 요약: “구체가 아니라 계약에 기대라.”2. DIP가 깨질 때 벌어지는 일비즈니스 로직 락인: 구현 세부 변경이 배포 리스크로 직격탄.테스트 지옥: 실 컨크리트 ..