오늘 TIL 3줄 요약

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

• 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶일 수 있도록 응집도를 높이자.

• 시스템의 결합도를 낮추면 유연성과 재사용성이 높아진다. 즉, 결합도를 최소로 줄이자.

TIL 날짜

2022.03.09

오늘 읽은 범위

10장. 클래스

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

• 책임, 즉 변경할 이유를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다. _p176

• SRP는 객체 지향 설계에서 더욱 중요한 개념이다. 또한 이해하고 지키기 수월한 개념이기도 하다. _p176

• 규모가 어느 수준에 이르는 시스템은 논리가 많고도 복잡하다. 이런 복잡성을 다루려면 체계적인 정리가 필수다. _p177

• 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다. 작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며, 다른 작은 클래스와 협력해 시스템에 필요한 동작을 수행한다. _p177

• OCP란 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙이다. _p188

• 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확정할 뿐 기존 코드를 변경하지 않는다. _p188

• 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다. _p189

• 이렇게 결합도를 최소로 줄이면 자연스럽게 또 다른 클래스 설계 원칙인 DIP를 따르는 클래스가 나온다. 본질적으로 DIP는 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다는 원칙이다.

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

• 상세한 구현에 익숙해져 있었던 것 같다. 이번 챕터의 ‘나쁜 예'에서 익숙한 안정감이 느껴져 ‘좋은 예'를 찬찬히 뜯어 보게 되었다. 코드가 길어지는 것과 영문권과 달라 길고 서술적인 변수명에 익숙해 지는 것에 아직은 시간이 많이 필요할 것 같다. 시스템의 지속적인 수정이 필요한 프로젝트의 경험이 적었던 탓인지, 책 앞서 언급하듯 ‘우리들 대다수가 프로그램이 돌아가면 일이 끝났다고 여기는 데 있다.’라는 나쁜 습관부터 버려야 할 것 같다.

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

• OCP란 클래스는 확장에 개방적이고...
  → 이 챕터에서 유독, 클래스의 확장이 무엇을 의미하는 바인지 햇갈렸다.

오늘 읽은 다른사람의 TIL

• https://nomadcoders.co/community/thread/3423
  → 인용에서 약간 필기하듯이 기록하셨는데, 한번 책을 보고 TIL를 둘러보니 왠지 생각의 흐름이 비슷하여 재미있어서 꼽게 되었다.

• https://nomadcoders.co/community/thread/3436
  → 큰 클래스를 지지하는 분을 만났던 경험이 비슷하여 공감이 갔다. 적어주신 경험과 같은 말을 들었던 적이 있었다. 지금 생각해보면 그분의 주관적인 생각이었던 것 같다.