클린 코드, 10. 클래스

클린 코드, 10. 클래스

표준 자바 관례

1. 변수
   1. public static 상수
   2. private static
   3. private
   4. public 변수가 필요한 경우는 거의 없다.
2. 함수
   1. public 메서드
   2. private 메서드는 호출하는 함수 직후에
3. 캡슐화
   테스트 코드에서 함수를 호출하거나 변수를 사용해야 한다면 protected로 선언하거나 패키지 전체로 공개한다. 하지만 이렇게 캡슐화를 풀어주는 것은 언제나 최후의 수단이다.

• 클래스는 작아야 한다.
  클래스의 크기는 클래스가 맡은 책임이다. 책임을 줄여야 한다.
  만능 클래스가 있다면 단일 책임 클래스 여럿으로 분리하도록 노력해야 한다.

  • 클래스 이름
    클래스 이름이 모호하다면 클래스에 여러 책임을 떠안겼다는 증거다.
    클래스 설명은 '만일', '그리고', '-하며', '하지만' 을 사용하지 않고 25단어 내외로 가능해야 한다. 그게 힘들다면 책임이 너무 많다는 증거다.
  • SRP(단일 책임 원칙)
    단일 책임 원칙은 클래스나 모듈의 책임, 즉 변경할 이유가 단 하나뿐이어야 한다는 원칙이다.
    작은 서랍 여러개에 컴포넌트를 분류하여 넣기 vs 큰 서랍에 싹 다 던져 넣기 (당연히 전자)
  • 응집도
    클래스는 인스턴스 변수 수가 적어야 하고 메서드는 인스턴스 변수를 하나 이상 사용해야 한다.
    일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스의 응집도가 높다.
    응집도가 높아지도록 변수와 메서드를 적절히 분리하고 응집도가 낮으면 클래스를 여러개로 쪼갠다.
  • 응집도를 유지하면 작은 클래스 여럿이 나온다.
    큰 함수의 부분을 작은 함수로 추출할 때 사용하는 변수를 인수가 아닌 인스턴스 변수로 승격하여 만들면 함수가 작아지고 매개변수 목록을 짧게 만들 수 있다고 했었다. 그런데 이렇게 하면 인스턴스 변수가 많아지므로 클래스의 응집도가 낮아진다.
    이렇게 응집도가 낮아진다면 클래스를 쪼개서 응집도를 유지하면 그만이다.
    (페이지 180, 큰 함수를 쪼내는 것으로 시작해서 클래스를 쪼개고 결과적으로 응집도를 높이거나 유지하는 너무 좋은 예시)

• 변경하기 쉬운 클래스
  어떤 변경이든 기존 클래스에 '손대어' 고치게 되면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다.
  깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

  • OCP
    클래스는 확장에는 개방적이고 수정에는 폐쇄적이어야 한다는 객체 지향 설계의 원칙.
    이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.

  작은 클래스 여럿으로 나누었을 때 SRP와 OCP를 지원하고 변경에 실제 변화하는 코드를 최소화 할 수 있다.

  • 변경으로부터 격리
    인터페이스와 추상 클래스를 사용하여 구현이 미치는 영향을 격리한다.
    클래스가 콘크리트 클래스의 상세한 구현에 의존하게 되면 그 구현의 변경에 수반하는 위험을 가지게 되고 테스트가 어렵다.
    그 대신 콘크리트 클래스가 아닌 인터페이스나 추상 클래스에 의존하면 테스트도 쉽고(다른 테스트용 구현체 사용) 변경으로부터 격리되어 있어서 안전하고 각 요소를 이해하기 쉬워진다.
    그리고 추상화는 실제 상세한 구현을 모두 숨길 수 있다.

    public class Portfolio {
        private StockExchange exchange;
    
        //추상화에 대한 구현체를 인수로 받는 생성자
        public Portfolio(StockExchange exchange) {
            this.exchange = exchange;
        }
    }

  • 결합도
    각 시스템 요소가 다른 요소에 의존하는 정도 그리고 변경으로부터 영향받는 정도.
    시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.

  • DIP
    클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 클래스 설계 원칙.
    결합도를 최소로 줄이면 DIP를 지원한다.