6. 관심사를 모듈로 분리하라

가이드라인

• 모듈 간 결합을 느슨하게 하기 위해 큰 모듈은 삼가한다

• 개별 모듈로 나누어 일을 시키고 구현 상세는 인터페이스 안으로 감춘다

• 강하게 결합된 코드베이스보다 느슨하게 결합된 코드베이스가 고칠 내용을 미리 살피고 실행하기 쉽다.

결합도가 높은 복잡한 시스템은 오래 사고가 난다.

-찰스 페로우의 정상 사고 이론 중에서

여기에서 모듈은 자바에서 클래스에 해당

1.필요성

• 클래스를 작게

• 클래스간 결합도 낮춤 -> 변경에 대한 부수효과가 줄어듬 (유연해짐)

• 작고 느슨하게 결합된 모듈(클래스)덕분에 코드베이스를 독립적으로 작업하고, 분석 및 따라가기 쉬움

  • 클래스는 한가지 책임을 갖는다. (SRP) -> 변경에 대해 다른 클래스에 영향을 미치지 않고 책임을 갖는 클래스만 변경하면 되도록 설계!!

• 관심사 분리가 안된 경우, 변경에 대해 종속적이고 부수적인 버그를 일으킬 수 있어서 변경에 대해 불안해 함

2.적용가이드

• 클래스는 한 가지 책임(관심)만 갖도록 작게 설계

• 외부에서 이 클래스를 호출하는 코드의 개수를 제한

최선의 개발 가이드라인

1. 클래스를 나누어 관심사를 분리한다.

   • 한 클래스에서 여러 책임을 갖는게 아니라 각각 적절히 나눔. A -> B,C,D로 나누어 관리 (SRP)

2. 특정 구현부는 인터페이스 안에 숨긴다.

   • 고수준 추상화, 구체적인 내용을 감춤 -> 변경용이

3. 커스텀 코드 -> 서드파티 라이브러리/프레임워크로 대체한다

   • 강한결합 일어나기 쉬운 곳 -> 제네릭한 기능 유틸기능 (StringUtils, FileUtils ...)

   • 코드베이스 곳곳에서 호출하고, 그러기 때문에 강한결합이 발생함 (변경하면 영향 받음)

   • 이럴때 클래스 크기를 제한하면서 커스텀 구현부를 오픈소스 라이브러리나 프레임워크로 대체 할 순 없는지 주기적으로 따져보는게 최선.

   • 아파치 커먼스 or 구글 구아바 같은 라이브러리나 Spring같은 프레임워크가 이에 해당됨

   • or 회사 자체 개발 (사내 솔루션 등)

3. 일반적인 반대의견

• 메서드의 호출을 늘리라는 것이 아님

• 클래스를 잘 디자인 (설계하면)... 이를 테면 상속 응용 or 인터페이스 안에 감출 수 있어서 구현부를 느슨하게 결합한 채 코드 재사용을 적극 유도

• 자바인터페이스가 느슨한 결합에 쓰라고 만든건 아님. 인터페이스를 클래스마다 , 클래스 앞에 두기 위해 인터페이스를 사용하는 것은 잘못된 이치. 최소한 2개이상의 클래스가 구현되어 추상화를 활용할 때 사용. 그외에는 클래스 나누기(관심사분리) 방식을 고려

• 공통기능 -> 프레임워크나 라이브러리를 찾아보자