TIL (Today I Learned)
2022.05.11
오늘 읽은 범위
10장. 클래스
책에서 기억하고 싶은 내용
추상화 단계가 순차적으로 내려간다. -172페이지
변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 캡슐화를 풀어주는 결정은 언제나 최후의 수단이다. -172페이지
클래스는 작아야 한다. -172페이지
클래스 이름은 해당 클래스 책임을 기술해야 한다. 간결한 이름이 떠오르지 않는다면 필경 클래스 크기가 너무 커서 그렇다. -175페이지
단일 책임원칙Single Responsibility Principle SRP은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. - 175페이지
게다가 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다. - 176~177페이지
"도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" - 177페이지
규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다. 그래야 (변경을 가할 때) 직접 영향이 미치는 컴포넌트만 이해해도 충분하다. - 177페이지
OCP란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다. - 188페이지
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. - 188페이지
DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다. -190페이지
오늘 읽은 소감은? 떠오르는 생각
게다가 많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 큰 그림을 이해하려면 이 클래스 저 클래스를 수없이 넘나들어야 한다고 걱정한다. - 176~177페이지
위에 있던 내용이 내가 요즘 고민하고 있던 것이었다. 많은 함수, 클래스, 파일로 나눠서 책임을 나누자니 정말 큰 흐름이 보이지 않을 것 같다는 생각이 들어서 조금씩 주저하는 마음이 생겼던게 사실이다. 하지만 아래 내용에 이런 마음은 싹 정리가 되었다.
"도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가? 아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?" - 177페이지
시간이 지날수록 조금씩 규모가 큰 프로그램을 개발하게 되는데, 정말 정리가 잘 되어있지 않으면 규모가 큰 프로그램에서 개발의 속도가 더 느려질수밖에 없다는 생각이 들었다. 나만의 체계를 잡아가는 시간이 필요한데, 너무 조급해하지 말고 천천히 시행착오도 거쳐가면서 포기하지 않으면 언젠가는 될 것이라는 긍정적인 마음을 가져본다.
지금은 node.js를 사용해서 서버 개발을 하고 있지만 언젠가 객체지향을 주로 다루는 날이 오면 이 장을 다시 보며 깨끗한 코드를 만들어봐야겠다.
댓글