9일차 - 캡슐화, 응집도 그리고 결합도

2023.08.09 WED

107p ~ 118p

 

8일차 내용 ⬇️

2023.08.09 - [개발 서적 기록/오브젝트_조영호] - 8일차 - 추상화를 통한 역할 부여 그리고 책임 중심 설계

8일차 - 추상화를 통한 역할 부여 그리고 책임 중심 설계

---

캡슐화

객체를 사용하면 변경 가능성이 높은 부분은 내부에 숨기고 외부에는 상대적으로 안정적인 부분만 공개함으로써, 변경의 여파를 통제할 수 있다.

캡슐화를 통해 추상화함으로써, 불안정한 부분과 안정적인 부분을 분리할 수 있고, 최종적으로 변경의 영향을 통제한다.

그래서 변경될 수 있는 것은 캡슐화해서 영향을 줄여야한다.

 

즉, 캡슐화는 유연한 유지보수를 위한 핵심/필수적인 행위이다.

응집도

응집도는 모듈에 포함된 내부 요소들이 연관되어 있는 정도이다.

모듈 내의 요소들이 하나의 목적을 위해 긴밀하게 협력할 때, 그 모듈은 높은 응집도를 가진다고 말한다.

그래서 적합한 책임을 부여했을 때, 응집도를 높일 수 있다.

결합도

어떤 도뮬이 다른 모듈에 대해 필요 이상의 자세한 부분까지 알고 있을 때, 즉 의존성이 높을 때, 두 모듈은 높은 결합도를 가진다고 말한다.

그래서 적절한 관계를 구성했을 때, 결합도를 낮출 수 있다.

 

응집도와 결합도 또한 변경을 고려해야한다.

객체 지향의 관점에서 응집도와 결합도가 중요한 요소인 이유는, 역시나 유연한 변경이다.

변경이 발생할 때 모듈 내부에서 발생하는 변경이 많다면, 어떤 모듈의 변경로 인해 그 모듈만 변경된다면, 응집도가 높기 때문이다.

동일하게, 어떤 모듈의 변경이 다른 여러 모듈이 함께 변경되어야한다면, 결합도가 높기 때문이다.

 

그래서 결합도를 낮추기 위해서, 클래스의 구현이 나닌 인터페이스에 의존하도록 코드를 작성해야한다. 

그리고 캡슐화를 위반하지 않아야한다. 캡슐화를 지키면 모듈 안의 응집도는 높아지고, 모듈 사이의 결합도는 낮아지기 때문이다. 

 

결합도가 높아도 상관없는 경우

결합도가 높지 않아야하는 이유는 변경때문이다.

하지만, 변경될 확률이 매우 적다면 결합도가 높아도 상관없고, 우리는 이미 무의식적으로 강한 결합도를 실천하고있다.

 

그러한 변경될 확률이 적인 안정적인 모듈은 아래와 같은 것들이다.

• 표준 라이브러리에 포함된 모듈
• 성숙 단계에 접어든 프레임워크
• 자바의 String
• 자바의 ArrayList

이런 안정적인 모듈이 아닌, 직접 작성한 코드는 무조건 변경이 일어날 수 있는 불안정한 코드이므로 결합도를 고려해야한다.

단순히 구현만 숨긴다고 캡슐화된게 아니다.

---

메서드 명만으로 인스턴스 변수가 존재한다는 사실을 퍼블릭 인터페이스에 드러낼 수 도 있다.

• ex ) 요금값을 반환하는 getFee 메서드는 내부 인스턴스 변수 fee가 있다는 것을 드러낸다.

객체가 저장할 데이터에 초점을 맞추면 이러한 오류를 범할 수 있다. 그래서 객체가 수행할 책임을 생각해야한다.

➡️ 데이터 중심 설계였기 때문이다!