스택큐힙리스트

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

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

“클라이언트는 자신이 사용하지 않는 메서드에 의존해선 안 된다.”― 로버트 C. 마틴SOLID 다섯 형제 중 네 번째, ISP(Interface Segregation Principle) 는 “세분화된 인터페이스”로 코드 의존도를 슬림하게 만드는 비법입니다.1. ISP가 왜 필요할까?쓸데없는 구현 강요 OUT거대한 인터페이스는 “안 쓰는 메서드”까지 구현하게 만들고, 결국 버그와 의존성 폭탄을 낳습니다. 변경 범위 최소화잘게 나뉜 인터페이스는 새로운 기능이 추가돼도 영향 범위가 좁아 회귀 위험이 적습니다.테스트·모킹이 쉬워진다필요한 기능만 담긴 인터페이스를 모킹하면 단위 테스트가 간단해집니다.2. ISP가 깨질 때 나타나는 신호‘God Interface’: 메서드 수십 개짜리 인터페이스를 구현하느라 빈 몸..

“하위 타입은 언제든 상위 타입을 대체할 수 있어야 한다.”1988년 바버라 리스코프가 제시한 이 정의가 바로 Liskov Substitution Principle(LSP)입니다. 상속·다형성이 진짜 힘을 발휘하려면 LSP가 지켜져야 하죠. 오늘은 현업 코틀린 예제와 국내 인기 블로그 사례를 묶어, “교체 가능한 설계”를 만드는 방법을 빠르게 살펴봅니다.1. LSP란 무엇인가?정의상위 타입을 기대하는 모든 곳에서 하위 타입을 넣어도 프로그램의 행위가 변하지 않아야 한다. 요컨대 “하위 타입이 상위 타입의 규약(계약)을 깨지 말라”는 약속입니다.왜 중요한가?예측 가능한 코드 ― 호출자가 “서프라이즈”를 안 당함리팩터링 자유도 ― 구현 교체해도 테스트가 그대로 통과재사용성 UP ― 라이브러리·플러그인 아키텍..