책임 찾기

단일 책임 원칙

모든 클래스는 단일 책임을 가진다. 즉, 모든 클래스는 시스템에서 단일 목적을 가지고 그 클래스를 변경하는 이유는 단 하나만 있어야 한다

인터페이스 분리 원칙

큰 클래스에서는 모든 클라이언트들이 해당 클래스에 있는 모든 메소드들을 사용하게 되는 경우가 드물다. 우리는 특정 클라이언트가 주로 사용하는 메소드들을 다른 방식으로 그룹화 하는 경우를 종종 볼 수 있다. 이러한 그룹화된 것들에 대한 각각의 인터페이스를 생성하고 그러한 인터페이스들을 구현하는 하나의 큰 클래스를 가지면, 모든 클라이언트는 특정 인터페이스를 통해 큰 클래스를 볼 수 있게 된다. 이렇게 함으로써 정보를 감출 수 있고 시스템 내의 의존관계를 줄일수 있다. 이제 클라이언트들은 그 큰 클래스가 재컴파일 할 때마다 자신들도 재 컴파일해야 했던 번거로움에서 벗어날 수 있다.

책임 찾기

1. 메소드들을 그룹화 하라
   비슷한 메소드 명들을 찾아보자. 접근 방식(퍼블릭, 프라이빗 등)과 함께 클래스 상의 모든 메소드들을 적어 보고, 묶을 만한 메소드들이 있는지 찾아보자
2. 숨겨진 메소드들을 살펴보라
   프라이빗 메소드들과 프로텍티드 메소드들에 주의하라. 하나의 클래스가 이런 프라이빗이나 프로텍티드 메소드들을 많이 가지고 잇다면, 해당 클래스 내에 간절히 밖으로 나오고 싶어하는 또 다른 클래스가 있다고 보면 된다
3. 변경할 수 있는 결정사항들을 찾아라
   결정사항들을 찾아야 한다. 코드 내에서 내리고 있는 결정사항들이 아니라 당신이 이미 해놓은 결정사항들을 의미한다. 데이터베이스와의 대화, 다른 객체들과의 대화 등 하드 코딩된 것처럼 보이는 작업을 수행하는 다른 방법이 있을까? 아울러 코드가 변경된다는 생각을 할 수 있을까?
4. 내부 관계들을 찾아내라
   인스턴스 변수들과 메소드들 사이의 여러 관계를 찾아라. 어떤 메소드는 특정 인스턴스 변수를 사용하는 반면에, 다른 메소드는 그 인스턴스 변수를 사용하지 않는 것은 아닌가?
5. 주된 책임을 찾아라
   클래스의 책임을 한 문장으로 기술하도록 하라
6. 다른 모든 방법이 실패할 경우, 스크래치 리팩토링을 어느 정도 사용하라
   한 클래스 내에 있는 책임들을 찾아내기가 쉽지 않다면 스크래치 리팩토링을 어느 정도 사용해 보는 것도 좋은 방안이다
7. 현재 작업에 집중하라
   지금 당장 처리해야 하는 작업에 주의를 기울여라. 어떤 작업을 수행하는 다른 방식을 제공하고 있다면 추출해야 할 책임 하나를 먼저 식별한 후에 그것에 필요한 대체를 허용하는 순으로 작업하라

출처: 레거시 코드 활용 전략 - 마이클 C. 페더스