6. 관심사를 모듈로 분리하라
가이드라인
모듈 간 결합을 느슨하게 하기 위해 큰 모듈은 삼가한다
개별 모듈로 나누어 일을 시키고 구현 상세는 인터페이스 안으로 감춘다
강하게 결합된 코드베이스보다
느슨하게 결합된 코드베이스가 고칠 내용을 미리 살피고 실행하기 쉽다.
결합도가 높은 복잡한 시스템은 오래 사고가 난다.
-찰스 페로우의 정상 사고 이론 중에서
여기에서 모듈은 자바에서 클래스에 해당
1.필요성
클래스를 작게
클래스간 결합도 낮춤 -> 변경에 대한 부수효과가 줄어듬 (유연해짐)
작고 느슨하게 결합된 모듈(클래스)덕분에 코드베이스를 독립적으로 작업하고, 분석 및 따라가기 쉬움
클래스는 한가지 책임을 갖는다. (SRP) -> 변경에 대해 다른 클래스에 영향을 미치지 않고 책임을 갖는 클래스만 변경하면 되도록 설계!!
관심사 분리가 안된 경우, 변경에 대해 종속적이고 부수적인 버그를 일으킬 수 있어서 변경에 대해 불안해 함
2.적용가이드
클래스는 한 가지 책임(관심)만 갖도록 작게 설계
외부에서 이 클래스를 호출하는 코드의 개수를 제한
최선의 개발 가이드라인
클래스를 나누어 관심사를 분리한다.
한 클래스에서 여러 책임을 갖는게 아니라 각각 적절히 나눔. A -> B,C,D로 나누어 관리 (SRP)
특정 구현부는 인터페이스 안에 숨긴다.
고수준 추상화, 구체적인 내용을 감춤 -> 변경용이
커스텀 코드 -> 서드파티 라이브러리/프레임워크로 대체한다
강한결합 일어나기 쉬운 곳 -> 제네릭한 기능 유틸기능 (StringUtils, FileUtils ...)
코드베이스 곳곳에서 호출하고, 그러기 때문에 강한결합이 발생함 (변경하면 영향 받음)
이럴때 클래스 크기를 제한하면서 커스텀 구현부를 오픈소스 라이브러리나 프레임워크로 대체 할 순 없는지 주기적으로 따져보는게 최선.
아파치 커먼스 or 구글 구아바 같은 라이브러리나 Spring같은 프레임워크가 이에 해당됨
or 회사 자체 개발 (사내 솔루션 등)
3. 일반적인 반대의견
메서드의 호출을 늘리라는 것이 아님
클래스를 잘 디자인 (설계하면)... 이를 테면 상속 응용 or 인터페이스 안에 감출 수 있어서 구현부를 느슨하게 결합한 채 코드 재사용을 적극 유도
자바인터페이스가 느슨한 결합에 쓰라고 만든건 아님. 인터페이스를 클래스마다 , 클래스 앞에 두기 위해 인터페이스를 사용하는 것은 잘못된 이치. 최소한 2개이상의 클래스가 구현되어 추상화를 활용할 때 사용. 그외에는 클래스 나누기(관심사분리) 방식을 고려
공통기능 -> 프레임워크나 라이브러리를 찾아보자
Last updated