책임 중심 설계

책임 중심 설계에 대한 이야기

• 객체지향 페러다임의 관점에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration)이다.

• 객체지향의 본질은 "협력하는 객체들의 공동체를 창조하는 것"이다.

객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다.

데이터 중심 설계에서 책임 중심 설계로 변경하기 위한 기준

• 캡슐화

• 응집도와 결합도

캡슐화

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

• 변경될 가능성이 높은 부분을 구현

• 상대적으로 안정적인 부분을 인터페이스

• 캡슐화의 정도가 응집도와 결합도에 영향을 미친다.

• 캡슐화를 지키면 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는 낮아진다.

응집도와 결합도

• 응집도(Coupling)

  • 모듈에 포함된 내부요소들이 연관되어있는 정도를 나타낸다.

• 결합도(Cohesion)

  • 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는 지를 나타내는 척도이다.

• 높은 응집도와 낮은 결합도를 가진 설계를 추구해야하는 이유

  • 설계를 변경하기 쉽게 만들기 때문이다.

  • 변경의 관점에서 응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다.

  • 응집도가 높을수록 변경의 대상과 범위가 명확해지기 때문에 코드를 변경하기 쉬워진다.

  • 결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있다.

객체지향 설계에 초점

• 협력

  • 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라 한다.

• 책임

  • 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다.

• 역할

  • 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다.

객체지향 설계하기

객체 지향의 가장 중요한 원칙은 캡슐화

• 내부의 데이터를 반환하는 접근자(accessor)

• 데이터를 변경하는 수정자(mutator)

캡슐화란

• 객체라는 단위 안에 데이터와 기능을 객체 내부로 함께 묶는 것을 캡슐화라 한다.

• 프로그래밍 언어들은 상태와 행동을 캡슐화하는 것에서 한 걸음 더 나아가 접근제어 매커니즘을 함께 제공한다.

• 프로그래밍 언어에서 접근 제어를 위해 public, protected, private과 같은 접근 수정자(access modifier)를 제공한다.

캡슐화와 접근 제어를 통한 객체의 분류

1. 외부에서 접근 가능한 부분인 퍼블릭 인터페이스(public interface)

2. 외부에서 접근 불가능하고 오직 내부에서만 접근 가능한 부분으로 구현(implementation)

인터페이스와 구현의 분리(separation of interface and implementation) 원칙은 훌륭한 객체지향 프로그램을 만들기 위해 따라야하는 핵심 원칙이다.

객체지향 프로그래밍 설계의 두 가지 조건

1. 어떤 클래스가 필요한지 고민하기 전에 어떤 객체들이 필요할 지 고민할 것

2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 볼 것

객치지향 프로그래밍 설계를 위한 자율적인 객체 작성하기

• 훌륭한 클래스를 설계하기 위한 핵심은 어떤 부분을 외부에 공개하고, 어떤 부분을 감출 지를 결정하는 것이다.

자율적인 객체에 대한 두가지 정의

1. 객체가 상태(state)와 행동(behavior)을 함께 가지는 복합적인 존재

2. 객체가 스스로 판단하고 행동하는 자율적인 존재