좋은 설계
오늘 요구하는 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 수용할 수 있는 설계
- 객체에게 올바른 책임을 할당한다.
- 결합도를 줄이고 응집도를 높인다.
위 원칙을 따르며 설계를 한다면 요구사항 변경에 대처하기 쉬워진다.
OOP는 객체 사이 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공하면서 좋은 설계를 도와주는 도구이다. 특히 캡슐화는 이를 효과적으로 지원해준다.
캡슐화
객체 지향 프로그래밍은 캡슐화를 통해 요구사항이 새롭게 추가되거나 바뀌어도 변경이 전파되지 않도록 막을 수 있는 장치들을 제공한다.
public interface vs implementation
- public interface 퍼블릭 인터페이스
- 외부에서 접근 가능한 객체의 행동
- 변경이 거의 없다.
- public method
- implementation 구현
- 외부에서 접근이 불가능하고 오직 내부에서만 접근 가능한 부분
- 변경이 발생할 수 있다.
- private method
변경 가능성이 높은 부분은 구현으로 숨기고, 외부에는 상대적으로 변경이 거의 없는 안정적인 부분만 공개함으로써 변경의 여파를 통제한다.
캡슐화의 정의
외부에서 알 필요가 없는 부분을 감춤으로써 대상을 단순화하는 추상화의 한 종류
캡슐화를 통해 변경 가능성이 높은 부분을 객체 내부로 추상화하면 변경을 최소화할 수 있다.
캡슐화 대상
- 변경될 수 있는 모든 것
- 객체의 상태
- 내부에서만 일어나는 행동
응집도 Cohesion
모듈에 포함된 내부 요소들이 연관되어 있는 정도
- 모듈 내의 요소들이 하나의 목적을 위해 긴밀히 협력한다면 그 모듈은 높은 응집도를 가진다.
- 모듈 내의 요소들이 각자 다른 목적을 추구한다면 그 모듈은 낮은 응집도를 가진다.
- 객체/클래스에 얼마나 관련 높은 책임들을 할당했는지를 나타낸다.
변경이 발생할 경우
변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도
하나의 변경을 수용하기 위해 모듈 전체가 함께 변경된다면 응집도가 높은 것이고, 모듈의 일부만 변경된다면 응집도가 낮은 것이다.
응집도 검사
- 모든 메서드들에 대해 인스턴스 변수를 사용하는 비율이 높은가?
- 메서드와 변수가 서로 의존하고 있음 → 높은 응집도
- 상태와 기능의 논리적 연결이 약함 → 낮은 응집도 → 클래스 분리 가능
- Stack 클래스는 size()를 제외한 모든 함수에서 인스턴스 변수를 활용하므로 응집도가 높은 클래스이다.
public class Stack { private int topOfStack = 0; List<Integer> elements = new LinkedList<Integer>(); public int size() { return topOfStack; } public void push(int element) { topOfStack++; elements.add(element); } public int pop() throws PoppedWhenEmpty{ if(topOfStack ==0) throws new PoppedWhenEmpty(); int element = elements.get(--topOfStack); elements.remove(topOfStack); return element; } }
결합도 Coupling
다른 모듈에 의존하고 있는 정도
- 다른 모듈에 대해 얼마나 많은 지식을 가지고 있는가
- 한 모듈이 다른 모듈에 대해 너무 자세한 부분까지 알고 있다면 두 모듈은 높은 결합도를 가진다.
- 한 모듈이 다른 모듈에 대해 꼭 필요한 지식만 알고 있다면 두 모듈은 낮은 결합도를 가진다.
변경이 발생할 경우
- 한 모듈이 변경되기 위해 다른 모듈의 변경을 요구하는 정도
- 내부 구현을 변경했을 때 다른 모듈에 영향을 미치는 경우 → 높은 결합도
- public 인터페이스를 수정했을 때만 다른 모듈에 영향을 미치는 경우 → 낮은 결합도
- 결합도가 높을수록 변경해야 하는 모듈의 수가 늘어나기 때문에 변경이 어렵다.
- 구현이 아닌 퍼블릭 인터페이스에 의존할 때 결합도가 낮아진다.
