Clean Code / 03 09 2022

클래스를 잘 만드는 법도 메소드를 작성하는 원리와 크게 다르지않다.

 

역시, 작고 간결하게 만드는게 포인트이다.

 

메소드는 보통 한 클래스 안에 다섯개 정도면 충분한데, 그 이유는

 

클래스가 너무 많은 책임을 안게되면 위험하기때문이다.

 

 

메소드와 함수의 예에서 설명했던것처럼, 이름이 모호한 클래스는 이름이 불분명해질 수 밖에 없다.

 

그 이유는 추상화가 제대로 이루어지지않았기때문인데,

 

추상화가 제대로 이루어지지않았다면 구현하는 기능이 명확히 정의되지않은것이고..

 

따라서 이름이 모호해질 수 밖에 없으며, 

 

모호하기때문에 많은 기능을 떠앉는 책임을 지게된다.

 

 

즉, 함수가 하나의 기능을 하는 것처럼,

 

클래스도 하나의 책임을 맡아야한다.

 

 

책에서 좋은 비유가 설명됐는데,

 

클래스를 도구상자에 비유했으며 메소드는 도구로 비유했다.

 

우리가 일을 하기위해 도구를 찾아서 쓴다고 가정할 때,

 

크고 잡다한 도구 상자 안에 갖가지 도구를 보관하여 찾는게 편하겠는가 혹은,

 

작고 여러개로 나누어진 도구 상자에 목적에 맞는 소량의 도구를 보관해 찾는게 낫겠는가.

 

답은 명확하다.

 

 

우리가 리팩토링을 하다보면

 

클래스의 응집도를 낮춰야할 경우가 있다.(응집도는 메소드와 변수들이 연결되어 사용되는 정도를 말하며 적정 수준으로 유지해야한다.)

 

함수를 쪼개고 사용하는 매개변수를 줄이다보면

 

필연적으로 클래스도 나누어야하는 경우가 생기는데,

 

이는 프로그램의 체계를 잡는 시발점이라고 볼 수 있겠다.

 

 

이 장은 읽으면서도 특히 공감이 많이 되었던 부분이다.

 

학원에서 했던 프로젝트를 다시 살펴보면 함수나 클래스를 쪼갰으면 더 좋았을 부분이 보이는데,

 

끔찍하지만 가끔 보면서 반면 교사인것같다.

 

지금도 크게 다르진않지만.

 

 

기억하자.

 

함수를 작게, 클래스도 작게, 매개변수는 최소로.