클래스 설계시에...

  눈도 고치고, 코도 고치고, 입도 고치고, 여기 저기 성형 수술한 사람을 얼마전 TV에서 보았다. 다들 놀랐다. 그렇게 많은 돈을 들여서 수술했음에도 우리가 생각했던 그런 미인은 아니였다. 이상하게 보이기까지 했다. 눈도 크고, 코도 오똑하고, 입술도 도톰하게 돈을 들이셨지만 결과는 망했다. 디테일도 중요하지만 얼굴이라는 전체적인 관점에서도 신경써야 한다.
  예쁜 코드도 이와 같다. 변수와 함수등에 신경을 많이 쓰더라도 클래스 관점에서 신경쓰지 않는다면 결국엔 노력하고도 좌절하는 일이 생긴다. Clean code는 clean class 없이는 불가능하다. 

클래스는 최대한 작게 만들자.
  변수를 수십개, 함수를 수십개 가진 클래스는 수정뿐만 아니라 사용하기도 어렵고 혼란스럽기까지 하다. 이 클래스틑 여러가지 이유로 변경되므로 보수 유지도 어렵게 한다. 이것 저것 다 쑤셔 넣어놓고 맥가이버 칼 같이 만능 클래스를 만들었다고 자랑스러워 하지 말자. 이것저것 남은 음식을 모아놓은 음식쓰레기와 같은 것을 만들었을 뿐이다. 그런것은 더럽고 다시 보고 싶지도 않다.
  그렇다면 얼마나 작아야 할까? 함수 10개? 5개? 1개? 함수나 변수 갯수의 기준을 숫자로 제한하기는 어렵다. 우선 클래스 이름에 해당 클래스의 모든 책임이 드러나게 이름을 지어보자. Manager, Super, Processor 등의 모호한 단어가 이름에 들어간다면 여러가지 책임을 하고 있을 것이다. 명확한 이름을 짓고 그에 해당하는 함수들만 모여 있어야 한다.
  클래스에 대한 설명도 적어보자. "~할 때에", "그리고", "~이거나", "~하지만", "~하면서", "~라면" 등의 말을 사용하지 않고 25단어 이내로 기술해보자. 이게 어렵다면 클래스를 책임에 따라 여러개로 나누어야 한다는 신호일 수 있다.

Single Responsibility Principle (SRP)
  잘 알려진 SOLID 법칙중 하나인 SRP는 클래스나 모듈의 변경 이슈가 하나여야 한다는 규칙이다. 대부분 SRP를 설명하면서 쉬운 규칙인데 잘 적용하지 않는다고 한다. 솔직히 고백하자면 나는 아직도 SRP가 어렵다. 우선 "책임"이란 것의 크기가 모호하다는 것이다. 내가 생각하는 "책임"과 동료가 생각하는 "책임"의 크기가 다를 수도 있다. 내가 어제 생각한 "책임"의 크기와 오늘 생각한 "책임"의 크기도 같다고 보장할 수 없다. 이러한 모호함을 없애기 위해 책임을 수정에 대한 이유로 정의 하기도 하지만 이 경우도 애매하다. 로버트 마틴은 actor를 기준으로 하면 모호함이 더 줄어든다고 한다. SRP는 그 자체 만으로도 큰 주제이므로 여기서 접어두고 다음으로 이야기를 이어가겠다.
  실제로 하나의 책임만 가지는 클래스로 잘게 나눈다는 것은 많은 연습을 해도 하기가 정말 어렵다. 인간의 두뇌는 비슷한 사실을 모아서 개념와 하도록 발달되었다. "둥굴고 빨간색이며 나무에 달린 것은 사과다." 라고 세상의 수많은 사과들을 하나의 개념으로 모은다. 이런 이유로 프로그램도 여러 비슷한 개념들을 자꾸 하나의 클래스나 모듈로 모아야 안심이 된다. 만능 클래스는 심리적 안정감을 주기까지 한다. 이것만 있으면 무엇이든 할 수 있다는 생각이 든다. 그러나 이런 저런 이슈로 그 클래스들을 수정할 때 쯤 되서야 내가 무슨 짓을 저질렀는지 후회하며 초과 근무를 하게 된다.
  최대한 잘게 나누자. 작은 것이 아름답다고 생각하자. 수많은 클래스에서 긿을 잃을 것이라고? 당신이 vi로 코딩하고 터미널에서 javac로 하나씩 컴파일하고 있다면 맞는 말일 수도 있다. 그러나 되도록이면 IDE를 사용하자. IDE는 멋진 네비게이션이 되어 줄 것이다. 우리는 많은 기능을 제공하는 무료 IDE를 사용할 수 있는 멋진 시대에 살고 있지 않은가. 

High Cohesion(높은 응집도)
  클래스는 내부 구성요소들이 똘똘 뭉쳐 있어야 한다. 한가지 수정하면 클래스내 여기저기를 고쳐야 하거나 클래스를 새로 짜야 한다면 응집도가 높은 것이다. 이상하게 들릴수도 있다. 한군데만 수정되는게 좋지 클래스를 통채로 수정한다고? 낮은 결합도(low coupling)과 같이 생각하면 이해하기 쉬울 것이다. 하나의 변경의 이유가 하나의 클래스의 변경만 가져오도록 하자는 것이다. 클래스 내부의 응집도는 높게, 클래스 사이의 결합도는 낮게 해서, 변경시 사고의 폭을 하나의 클래스로 제한하자는 것이다.
  높은 응집도를 가진 클래스는 자연스럽게 그 크기가 작아진다. 클래스의 각 메소드들은 거의 모든 멤버변수들을 골고루 사용한다. 몇개의 함수들이 일부 변수만 집중적으로 사용한다면 이들은 별도의 클래스로 분리 해야 한다. 이때 분리해야 할 함수들이 privat 속성이라 망설이게 되는 경우도 있다. 모두 공개되지 말아야할 내부 함수처럼 보일 수도 있다. 이런 경우 별도의 클래스로 분리하게 되면 public으로 공개해도 되는 면제부가 생긴다고 생각하자. 새로운 클래스로 위치가 바뀌었으니 공개의 기준이 바뀌는 것은 당연하다. 브라질에서 후보였던 축구 선수가 다른 나라로 옮기고 주전이 된다고 해서 이상하게 생각할 것은 아닌듯하다.

  좋은 클래스를 만드는 방법은 여기서 이야기 한 것들이 전부는 아니겠지만, 기본적으로 중요한 부분들은 대부분 조금씩 언급한듯하다. 물론 너무 짧은 지면에 많은 이야기를 하려다보니 이해가 잘 안되는 내용도 있을 것이다. 짧은 글 하나로 하루 아침에 모든 것을 이룰 수는 없다. 보수유지 하기 쉬운 클래스를 만드는 방법을 알기위해 공부해야 할 것들에 대한 화두를 던질 글 정도로 봐줬으면 한다.



출처 : http://dsmoon.tistory.com/category/Programming/Clean%20code%20%28by%20D.%20Moon%29