[클린 코드] 클래스

nn·2022년 5월 10일
0

clean-code

목록 보기
8/9

오늘 TIL 요약

  • 단일 책임 원칙
  • 응집도가 높으면 변수와 메소드를 분리해 새로운 클래스로 쪼개준다.
  • 변경으로부터의 격리

7장. 오류 처리

책에서 기억하고 싶은 내용

  • 함수는 물리적인 행 수로 크기를 작게 만들었다면, 클래스는 책임을 센다. (p.173)
    클래스 이름은 해당 클래스의 책임을 기술해야한다.
    하지만 이름이 모호하거나 if, and, or, but을 사용한다면 그것은 클래스가 너무 많은 책임을 지고있다는 증거이다.
    클래스마다 하나의 책임을 가지도록 하면 추상화가 더욱 쉬워진다.

    "도구들을 이름과 기능을 명확하게 나누어 작은 서랍에 나누어 넣고 싶은가? 큰 서랍에 모두 던져 넣고 싶은가?"

  • 응집도가 높다는 말은 클래스에 속한 메소드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다. (p.177)
    다만 '메소드는 더욱 작게, 변수 목록도 짧게'라는 전략을 따르다보면 몇개의 메소드에서만 사용하는 변수들이 아주 많아진다.
    이런 메소드와 변수는 적절히 다른 클래스로 분리해주자.

  • 요구사항은 변하기 마련이다. (p.189)
    인터페이스와 추상클래스를 구별하여 구현에 미치는 영향을 최소화하자.
    테스트를 해야한다면 테스트용 인터페이스와 클래스를 만들자.
    시스템끼리의 결합도가 낮아지면 유연성과 재사용성이 증가한다.

소감
하나의 클래스에 너무 많은 책임을 준 적이있다.
결국 그 클래스는 구현시 너무나 많이 등장하였고, 많은 수정을 해야했다.
클래스를 쪼개지 않은 번거로움을 느끼고 있으면서도, 그것이 '만능 클래스'였기 때문이라는 것을 깨닫는데엔 시간이 꽤 걸렸었다.
더 이상 아는 것에서 멈추지 말고 실행을 해보자
화이팅!

profile
내가 될 거라고 했잖아

0개의 댓글