오늘 TIL 3줄 요약

• 클래스는 큰 함수를 작은 함수로 쪼개듯 작게 작게 쪼갠다.

• 클래스는 단일 책임 원칙으로 만든다.

• 클래스는 변경하기 쉬워야 한다.

TIL (Today I Learned) 날짜

2022.05.10

오늘 읽은 범위

10장. 클래스

책에서 기억하고 싶은 내용을 써보세요.

1. 클래스 체계

   클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나온다.

   • 정적 공개 상수가 있다면 맨 처음 나온다.

   • 정적 비공개 변수

   • 비공개 인스턴스 변수

   변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다.

   변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 protected를 선언함으로 패키지 전체로 공개하기도 하지만 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다.

2. 클래스는 작아야 한다!

   클래스를 만들 때 첫 번째 규칙은 크기다. 클래스는 작아야 한다. 두번째도 크기다. 더 작아야 한다. 함수와 마찬가지로 ‘작게'가 기본 규칙이다.

   • 얼마나 작아야 하는가?

     함수는 물리적인 행 수로 크기를 측정했다면, 클래스는 클래스가 맡은 책임을 센다. 클래스의 이름은 해당 클래스 책임을 기술해야 한다. 실제로 작명은 클래스 크기를 줄이는 첫 번째 관문이다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. 모호하다면 책임이 너무 많아서다. 클르스 설명은 만일, 그리고, 하며, 하지만을 사용하지 않고 25단어 내외로 가능해야 한다.

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

     단일 책임 원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나 뿐이어야 한다는 원칙이다. SRP는 ‘책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 책임, 즉 변경할 이유가 하나여야 한다는 의미다.

     SRP는 객체 지향 설계에서 더욱 중요한 개념이다. 이해하고 지키기 수월한 개념이기도 하다. 하지만 이상하게도 SRP는 클래스 설계자가 가장 무시하는 규칙중 하나.

     소프트웨어를 돌아가게 만드는 활동과 소프트웨어를 깨끗하게 만드는 활동은 완전히 별개다. 우리들 대다수는 두뇌 용량에 한계가 있어 ‘깨끗하고 체계적인 소프트웨어'보다 ‘돌아가는 소프트웨어'에 초점을 맞춘다. 문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. 프로그램으로 되돌아가 만능 클래스를 단일 책임 클래스 여럿으로 분리하는 대신 다음 문제로 넘어가버린다.

     게다가 많은 개발자들은 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 하지만 클래스가 많은 시스템이든 큰 클래스가 몇 개 뿐인 시스템이든 돌아가는 부품은 그 수가 비슷하다. 어느 시스템이든 익힐 내용은 그 양이 비슷하다. ‘도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇개를 두고 모두를 던져 넣고 싶은가?’

   • 응집도

     클래스 메서드가 변수를 더 많이 사용할 수록 메서드와 클래스는 응집도가 더 높다. 일반적으로 응집도가 높은 클래스는 가능하지도 바람직하지도 않다. 때때로 몇몇 메서드만이 사용하는 인스턴스 변수가 많아질수록 새로운 클래스로 쪼개야 한다는 신호다.

     큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.

3. 변경하기 쉬운 클래스

   • 대다수 시스템은 지속적인 변경이 가해진다. 그리고 뭔가 변경할 때마다 시스템이 의도대로 동작하지 않을 위험이 따른다. 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다.

     요구사항은 변하기 마련이다. 따라서 코드도 변하기 마련이다. 객체 지향 프로그래밍 입문에서 우리는 구체적인(concrete)클래스와 추상(abstract)클래스가 있다고 배웠다. 구체적인 클래스에는 상세한 구현(코드)을 포함하며 추상클래스는 개념만 포함한다고도 배웠다. 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

‘돌아가는 프로그램을 깨끗하고 체계적인 소프트웨어라는 다음 관심사로 전환하지 않는다’라는 말이 허를 찔렀다. 사이드 프로젝트처럼 작은 관리자 페이지를 외주받아 작업을 한 적이 있는데, 계속해서 내가 유지보수를 해야함에도 불구하고 큰 이슈가 없다하니 다음 단계로 넘어가지 않고 미루고 있었다. 어제 짠 코드도 오늘 보면 새롭거늘 왜 다음으로 넘어가지 않을까 생각해보니, 손을 대면 버그가 생기니까 다음으로 전환하지 못하고 있었다. 정말이지 책에서 말하는 더러운 코드, 단위테스트를 하지 않으면 발생하는 일들의 예제가 나의 경우였다. 하하. 다시 돌아가서 작은 단위로 쪼개면서 시작해야겠다. 책을 읽었다고 좋은 코드를 짤 수 있는게 아니니까. 하나씩 실천으로 옮기기!

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

오늘 읽은 다른사람의 TIL