[클린 코드] 클래스의 단일 책임 원칙 (Single Responsibility Principle)

 

 

 

*본 게시물은 [클린 코드] 서적에서 배운 것 들을 잘 활용하기 위해 해당 서적을 정리한 글입니다.

*문제시 삭제하겠습니다.

---

클래스의 체계

변수 목록이 가장 먼저 나오며, 추상화 단계의 순서대로 작성한다.

static과 public 상수 다음으로 정적 비공개 변수, 마지막으로 비공개 변수 순서를 지키자.

(공개 변수는 사용할 일이 거의 없어야 한다.)

비공개(private) 함수는 자신을 호출하는 공개(public)의 직후에 작성하자.

 

 

캡슐화

캡슐화를 해제하는 결정은 언제나 최후의 수단이어야 한다.

 

 

 

함수를 만드는 규칙은 첫번째도 작게, 두 번째는 더 작게이다. 이는 클래스에서도 동일하다.

함수는 실질적인 라인수로 측정을 할 수 있었다면, 클래스에는 다음과 같은 측도가 있다.

 

단일 책임 원칙 (Single Responsibility Principle, SRP)

 

 클래스 이름은 드 책임을 기술해야 한다. 만약 클래스의 작명이 if, and, or과 같은 단어가 들어가야 한다면 분명 너무 많은 책임을 떠안고 있는 것이다.

단일 책임 원칙이란 클래스나 모듈을 변경할 이유가 단 하나 뿐이어야 한다는 원칙이다.

 

예를 들어 비지니스 로직과 UI로직을 하나의 클래스에 담아두었다 생각해보자.

 

public class Car {
    private int position;
 
    // 자동차 이동 여부를 결정하는 비즈니스 로직
    public void move(int randomValue) {
        // randomValue값이 특정값 이상일때 위치를 변경
    }
 
    // UI 로직
    private void print(int position) {
        StringBuilder sb = new StringBuilder();
        ...
        // 위치를 특정 형식으로 출력 
    }
}
 

 

이러한 클래스는 두가지 이유로 변경될 수 있다.

1.  자동차의 이동 여부를 변경해야 할 때

2.  출력 형식이 변경돼야 할 때

따라서 비즈니스 로직과 UI로직을 다른 클래스로 분리해주어야 한다.

 

 일단 '돌아가는 소프트웨어'에 초점을 맞추다 보면 만능 클래스를 단일 클래스로 분리하지 않는다.

만능 클래스 하나가 더 시스템을 파악하기 쉽다고 생각할 수 있지만, 결국 시스템을 구성하는 부품의 양과 구성은 같기 때문에 기능 별로 나누어 담아 관리하는 것이 현명할 것이다.

 

응집도 Cohesion

 

 응집도가 높은 클래스는 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.

변수가 많은 큰 함수 하나에서 작은 함수로 빼내려 할 때, 작은 함수가 큰 함수의 인스턴스 변수 4가지를 사용한다고 생각해보자.

이 4가지 변수를 모두 새 함수의 인수로 넘기기 보단, 클래스의 인스터스 변수로 승격하는 것이 함수를 쪼개기 쉬어질 것이다.

하지만, 이런 방식은 몇몇 함수만 사용하는 인스터스 변수를 증가시켜 클래스의 응집력을 떨어트린다. 

몇몇 함수만 사용하는 변수가 있다면, 바로 독자적인 클래스로 분리할 때이다.

클래스가 응집력을 잃는다면 클래스를 쪼개자!