TIL (2024.02.11-12)
📖 오늘 읽은 범위: 10장. 클래스
✍️ 책에서 기억하고 싶은 내용
- 클래스를 정의하는 표준 자바 관례에 따른 클래스 체계 - 추상화 단계가 순차적으로 내려간다!
- 변수 목록
- 정적 공개 상수
- 정적 비공개 상수
- 비공개 인스턴스 변수
- 공개 함수
- 비공개 함수(자신을 호출하는 공개 함수 직후)
- 변수 목록
- 클래스는 작아야 한다.
- 클래스 이름은 해당 클래스 책임을 기술해야 한다.
- 클래스 이름이 모호하다면 클래스 책임이 너무 많다는 것.
- 단일 책임 원칙(Single Responsibility Principle)
- 클래스나 모듈을 변경할 이유(=책임)가 단 하나뿐이어야 한다는 원칙
- 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
- 응집도(Cohesion)
- 응집도가 높다 = 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다
- 클래스가 응집력을 잃는다면 쪼개라.
- 개방-폐쇄 원칙(Open-Closed Principle)
- 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다.
- 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.
- 의존성 역전 원칙(Dependency Inversion Principle)
- 클래스는 상세한 구현이 아니라 추상화에 의존해야 한다.
- 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바꾸면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다.
- 시스템의 결합도를 낮추면 유연성과 재사용성도 높아진다. 이렇게 결합도를 최소로 줄이면 자연스럽게 DIP를 따르는 클래스가 나온다.
💭 오늘 읽은 소감과 떠오르는 생각
문제는 우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다. '깨끗하고 체계적인 소프트웨어'라는 다음 관심사로 전환하지 않는다.
- 완전 나다. 하하.. 필자가 말한 것처럼 대다수가 저렇게 생각하지 않을까? 일단 돌아가게 짜두면 그 이후에는 괜히 건들었다가 돌아가지 않을까봐 겁이 나서 최대한 건들지 않으려고 했다. 아직은 구현하는 것조차 어려운 실력이라서 어쩔 수 없는 것 같다. 그렇지만 마인드가 가장 중요하지 않은가? 기능 구현에 신경쓰면서도 틈틈이 깨끗한 코드에 대한 고민을 하고 적용해볼 수 있도록 노력하자.
- 정처기를 공부하면서 SOLID 원칙에 대해서 무작정 외우기만 했었는데, 이렇게 책에서 예제와 함께 보니 각 원칙이 왜 존재하는지 알 수 있었다. 역시 그냥 자격증을 따기 위해서 하는 공부랑, 내가 궁금해서 직접 찾아보는 것은 천지차이인 것 같다. 앞으로도 능동적으로 공부하는 사람이 되어야겠다고 다짐해본다.
- 클래스에 되는대로 기능을 이것저것 추가하고는 했었는데, 나중에 수정하려고 보니 온갖 곳을 수정해야 해서 힘들었던 기억이 많다. 그냥 원래 다들 이러는 줄 알았는데(😰), 애초에 짤 때부터 잘못 짠 것이었다는 것을 확실히 알게 되었다. 되는대로 짜지 말고, 설계하고, 생각하고 코딩하자.
🤨 궁금한 내용 또는 잘 이해되지 않는 내용
X
