객체가 스스로 GUI에 그리는 법을 알아야 한다거나 디스크에 저장하는 법을 알아야 한다거나 XML로 변환하는 법을 알아야 한다거나 하는 등.. 객체가 다양한 책임을 떠안고 있는 구조를 좋은 설계라고 말하기 어렵다.
아래 클래스는 너무 많은 일을 하고 있다. 이 클래스를 변경해야하는 다양한 이유가 있다. 또한 '부서지기 쉬움'의 냄새도 난다.
가령, XML API를 SAX에서 JDOM으로 바꾼다면 Employee 또한 수정되어야한다. 세금 보고서의 형식을 바꾼다면, 마찬가지로 Employee 또한 변경의 여지가 있다. 이 설계는 결합도가 너무 높다.
위 Employee 클래스가 떠 안고 있는 역할들을 각기 다른 클래스로 분리하여 클래스마다 변경해야하는 이유가 오직 하나씩만 존재하도록 고립하는 것이 바람직하다.
다음과 같이 Employee가 떠안고 있던 역할을 나누어 놓아서 '변경'의 이유를 때어 놓았다.
특정 속성을 부여하는 인터페이스를 하나 또는 그 이상으로 구현하는 클래스들도 주의해야한다.
예를 들어, 디스크에 저장하는 능력처럼 어떤 객체에 특정 능력을 부여하는 인터페이스를 생각해보자. 비즈니스 로직 객체가 조심성 없이 이런 인터페이스까지 구현하면 영속성 문제와 비즈니스 규칙 사이에 필요없는 결합을 만들기 쉽다.
아래 예제를 보자.
