안티패턴은 합리적으로 보이지만 설계를 저하시키는 반복되는 "해법"입니다. OOP에서 가장 흔한 것은 God Object(전지전능 객체), 깊은 inheritance 계층 구조, 그리고 **Anemic Domain Model(빈약한 도메인 모델)**입니다.
너무 많이 알고 너무 많이 하는 class — Single Responsibility를 위반합니다.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
각 레벨이 모든 조상에 결합됩니다. 상위 근처의 변경이 모든 곳으로 파급됩니다(깨지기 쉬운 기반 클래스). 해법: composition으로 평탄화하고, 깊은 "is-a" 체인보다 "has-a" 능력을 선호하세요.
모든 로직이 다른 곳에 있고 getter/setter 봉지에 불과한 객체들 — 이름만 OOP입니다.
// ANEMIC: 동작 없는 데이터; 규칙은 별도의 "service" 에 존재
class Order { List<Item> items; double total; /* getter/setter 만 */ }
class OrderService { double calcTotal(Order o) { ... } } // 로직이 추방됨
// RICH: 동작이 그것이 다루는 데이터와 함께 존재
class Order {
private List<Item> items;
double total() { return items.stream().mapToDouble(Item::price).sum(); }
}
→ 요요 문제 (로직을 따라가려고 깊은 계층을 위아래로 점프)
→ 순환 의존성 (A 가 B 를 필요로 하고 B 가 A 를 필요로 함)
→ 기능 욕심 (주로 다른 class 의 데이터를 사용하는 메서드)
안티패턴은 좋은 의도가 썩는 방식입니다: God Object는 보통 작은 헬퍼로 시작하고, anemic 모델은 "그냥 DTO"로 시작했다가 굳어집니다.
이름을 붙이면 팀에게 코드 리뷰에서 공통 조기 경보 어휘를 제공하며, 각 안티패턴은 이를 고치는 원칙(SRP, composition, encapsulation)을 직접 가리킵니다.