[Programming] - CleanCode 10. 클래스

in Programming on Programming, Cleancode


클래스 체계

추상화 단계는 순차적으로 내려간다. 마치 신문기사 처럼 읽힌다.

자바에서는 static public 상수 ⇒ static private 상수 ⇒ private 변수 (공개 변수는 거의 없다) ⇒ public 함수 ⇒ private 함수

캡슐화

  • 변수와 유틸리티 함수를 숨기는게 낫지만 가끔은 test를 위해서 protected를 해주기도 한다.
  • 캡슐화를 풀어주는 결정은 언제나 마지막 최후의 방법이다.

클래스는 작아야 한다!

  • 클래스는 작아야한다. 또 작아야 한다. 작아야 한다!! (매우 강조!!!)

  • 함수는 행의 숫자로 크기를 측정했다면, 클래스는 맡은 책임을 세야 한다. (SRP: 단일 책임 원칙)

  • 클래스 작명은 클래스 크기를 줄이는 첫번째 관문이다.
    • 간결한 이름이 떠오르지 않는다면 이미 너무 크다는 증거다.
    • Processor, Manager, Super 처럼 모호한 단어가 있다면 여러 책임을 떠안겼다는 증거다.
    • 클래스 이름안에 if, and, or, but 등이 들어가지 않고 25단어 내외여야 한다.

단일 책임 원칙 (Single Responsibility Principle)

  • 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다.
    • 클래스는 책임, 즉 변경할 이유가 하나여야만 한다.

변경할 이유를 파악하려 애쓰다보면 추상화 하기도 쉬워진다. 이 클래스의 변경이 일으키는 경우들을 생각해보자!

  • SRP는 객체지향 설계에서 더욱 중요하지만 가장 무시하는 규칙이다.
  • 우리는 모두 일단 ‘돌아가는 소프트웨어’에 초점을 맞추고 올바른 태도이다.
  • 그러나, 그 다음 관심사로 ‘깨끗하고 체계적인 소프트웨어’로 전환해야한다.
    • 대부분 전환하지 않는다.

응집도

  • 클래스 인스턴스 변수가 작아야 한다.
  • 응집도가 높다 : 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.

  • 큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다.

    몇몇 함수가 몇몇 변수만 사용한다면 독자적인 클래스로 분리해라!

변경하기 쉬운 클래스

  • 대다수 시스템은 지속적인 변경이 가해진다. 그럴때마다 오류의 위험에 빠진다.
    • 어떤 변경이든 클래스에 손을 대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재한다.
  • OCP 원칙을 지키며 변경에서 자유롭게 수정하는 방법도 있다.
    • 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지 않는다.

변경으로부터 격리

  • 요구사항은 변하기 마련이다. 따라서 코드도 변한다.
  • 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다.
    • 그래서 추상 클래스를 통해 구현한다.
    • 클래스 설계 원칙인 DIP(Dependency Inversion Principle)을 따르자.
      • 상세한 구현이 아니라 추상화에 의존해야한다는 내용

결론

저번 프로젝트에서 유저와 관련된 로그인, 회원가입도 AuthViewModel에서 다 관리했는데 이걸 보면서 더욱더 AuthViewModel은 회원가입 로그인 관련된 기능만 관리하고, User와 관련된 것은 UserViewModel에서 관리해야겠다는 생각이 들었다.

개발을 하다보면 한장에서 모든걸 하고 싶은 유혹에 빠진다.

또한, 이 기능이 돌아가는지 먼저 확인을 해봐야 한다는 불안감 때문에 코드의 개선보다는 위에서 말한것 처럼 일단 돌아가게 짜게 된다.

정상적으로 돌아가는 코드를 보고 나서, 개선과 깨끗한 설계를 해야하지만 이미 정상적으로 돌아가는 코드를 짜는데 에너지를 써버리고 가끔 넘어가버린 내가 떠올랐다.

이제는 장인정신 마인드로 내 코드를 리뷰하는 사람들을 위해서 (현재는 내 코드를 리뷰하는 사람이 거의 없다…) 더욱 더 코드를 신문기사와 같이 글을 쓰듯이 써봐야 겠다.

하지만 이것도 정도를 지키는게 중요한게 코드를 열심히 개선해놨는데 자다보면 더 좋은 구조가 떠오른다… 그렇게 개선하다보면 코드 순서가 다시 엉키고 그걸 풀어주다보면 어느순간 정리를 포기하게 되는 나를 발견했다.

코드의 개선도 깔끔함의 기준도 없기에 (내가 모르는 것일 수도…) 그것의 스스로의 기준을 만들어가야 할 것 같다.