Class 나누기

오늘도 고민이 됩니다.

어떻게 Class를 나눠놔야 잘 나눠 놨다고 칭찬 받을지..

원칙은 이러합니다.
하나의 책임에 하나의 Class.

그런데 이 책임을 설정하는게 참.. 뭐랄까..
코에 붙이면 코걸이요. 귀에 붙이면 귀걸이라는 생각이 듭니다.

사람이 하는 말도 그렇지요.
말 하기 나름이고 정하기 나름이지요.

예를 들어서 나는 특정 명령을 Execute 하는 Class를 만들고 싶습니다.
그런데 이러한 Executing 을 반복적으로 수행해야 하는 요구사항이 생겼습니다.

이러한 경우...
Execute 와 반복이라는 두개의 책임으로 나누어 Class를 두개 생성 할 수도 있고
아니면 어차피 실행이니깐 Execute라는 하나의 Class에 반복이라는 Method를 생성해서 역할을 할당 할 수도 있습니다.

작가가 글을 쓰기 나름인 것처럼 Programming 도 쓰기 나름입니다.

하지만 원칙에 입각하여 생각해 보자면 두개를 나누는게 더욱 좋은 모습일 것 같습니다.
왜냐하면 만일 새로운 요구사항 ..
예를 들어 반복을 하게 되는데 나는 짝수번에 해당하는 녀석들만 반복하고 싶어 라는 요구사항이 나올 수 있기 때문이죠.
물론 이건 아직 나오지 않은 요구사항이므로 미리 대비하여 만들어 놓을 필요는 없습니다.

하지만 위와 같은 요구사항이 도출되는 경우 Method를 추가하여 요구사항을 받아 들일 수도 있지만 그렇게 되면 점점 Class는 커지게 되지요.

그렇다고 미리 걱정하여 여러 Class로 조각 내어 놓는다면 관리하기가 쉽지 않겠네요.
하지만 계속적인 변화가 있는 Code라면 책임에 따라 조각을 내어 놓는 것이 좋을 것 같아요.
Unix가 이런 원칙에 근거해서 설계 되었다고 합니다.