변수 목록(정적 공개 상수 -> 정적 비공개 변수 -> 비공개 인스턴스 변수) -> 공개 함수 -> 공개 함수가 호출하는 비공개 함수 순으로 추상화 단계가 순차적으로 내려간다 - p.172
캡슐화 : 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙은 없다. 테스트 코드의 경우에는 공개하는 부분이 필요하다. 하지만 그 전에 비공개 상태를 유지할 방법을 강구해야한다. - p.172
클래스는 작아야 한다! : 클래스를 만들 때 첫번째도 두번째도 크기가 작아야한다. 함수와 클래스는 '작게'가 기본 규칙이다. 클래스의 크기는 맡은 책임으로 센다. - p.172
클래스 이름은 해당 클래스의 책임을 기술해야 한다. 작명은 클래스 크기를 줄이는 첫 번째 관문이다. - p.175
간결한 이름이 떠오르지 않음 = 클래스 크기 너무 큼, 이름이 모호함 = 클래스 책임 너무 많음 - p.175
단일 책임 원칙 : 단일 책임 원칙(Single Resposibility Principle, SPR)은 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙이다. 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. - p.175
SPR은 클래스 설계자가 가장 무시하는 규칙이기도 하다. 프로그램이 돌아가면 일이 끝났다고 생각하면 '깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않기 때문이다. - p.176
많은 개발자는 자잘한 단일 책임 클래스가 많아지면 큰 그림을 이해하기 어려워진다고 우려한다. 하지만 작은 클래스가 많은 시스템 = 큰 클래스가 몇 개뿐인 시스템 둘의 돌아가는 부품의 수는 비슷하다. - p.176
규모가 어느 수준에 이르는 시스템은 논리가 많고 복잡해지니 이런 복잡성을 다루려면 체계적인 정리가 필요하게 된다. - p.177
바람직 : 큰 클래스 몇 개 < 작은 클래스 여럿
작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다. - p.177
응집도(Cohesion) : 클래스 인스턴스 변수 수가 작아야 한다. 일반적으로 메서드가 변수를 더 많이 사용할수록 메서드와 클래스는 응집도가 더 높다. 응집도가 높다는 말은 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다. 응집도가 높아지면 -> 변수와 메서드 분리해 새로운 클래스로 쪼개기 - p.177
응집도를 유지하면 작은 클래스 여럿이 나온다 : 큰 함수를 작은 함수 여럿으로 나누기만 해도 클래스 수가 많아진다. 클래스가 응집력을 잃게 된다면 쪼개야 한다. 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다. - p.178
프로그램 동작 검증하는 테스트 슈트 작성 -> 한 번에 하나씩 코드 변경 -> 코드를 변경할 때마다 테스트 수행하여 원래와 동일한지 확인 -> 정리한 결과 최종 프로그램
변경하기 쉬운 클래스 : 대다수 시스템은 지속적인 변경이 가해진다. 어떤 변경이든 클래스에 손대면 다른 코드를 잠정적인 위험이 존재한다. 하지만, 깨끗한 시스템은 클래스를 체계적으로 정리해 변경에 수반하는 위험을 낮춘다. - p.185
새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 스세팀 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. - p.188
변경으로부터 격리 : 요구사항은 변하기 마련이며 이에 따라 코드도 변한다. 상세한 구현에 의존하는 코드는 테스트가 어렵게 된다. - p.189
결합도를 낮추면 유연성과 재사용성도 더욱 높아진다. 결합도가 낮다는 것은 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미이다. 잘 격리되면 각 요소를 이해하기 쉬워진다. - p.190
📝오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
함수를 사용하기는 하지만 아직 클래스에 대해서는 예전에 언급했듯이 어색한 부분이 존재하는 것 같다. 완전하게 이해하지 못했다고 느껴서 클래스를 사용하면서 궁금했던 부분들이 있었다. 왜 함수에 하나씩 부분 동작으로 나누서 만들까 이런 생각도 했었고 이렇게 작게 함수를 단위를 쪼개고 그런 부분들이 궁금했다. 책에서 궁금했던 부분들이 잘 다뤄주어서 좋았다.
실무에서도 책과 동일하게 하기 위해서 한번 더 작명에 신중을 더하게 되었다. 아직 100% 이해했다고 말하기에는 많이 부족하다. 그렇기에 정석의 책처럼 놓고 한번씩 확인하고 다시 다짐하게 해주는 계기의 책이 될 것 같다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
DIP :
DIP(Dependency Inversion Principle)란 배웠던 추상화 개념을 생각하면 된다. 상위의 모듈이 하위의 모듈의 구현에 의존해서는 안된다라는 의미이다.
