2011/11/13 20:50
객체설계[4] - 객체지향 설계 원칙(기본) 패턴/객체지향2011/11/13 20:50
우리는 나이가 들면서 중요한 것을 가끔 잊고 삽니다. 하지만 가끔씩 이런 것을 어린 아이들로부터 다시 배우기도 합니다. 그 중 하나가 '왜?'라는 질문입니다. '왜?'라는 질문에 화를 내는 이유는 내가 모르는 것을 인정하기 싫거나, 특별한 이유없이 나의 생각을 상대방에게 강요하고 있다는 불편한 진실을 드러내고 싶지 않기 때문이라고 생각합니다.
하지만 개발자라면 이 '왜?'라는 질문을 적극적으로 하고, 스스로 답을 찾는 노력이 반드시 필요합니다. 마찬가지로 우리가 객체지향 설계 원칙을 따르는 이유에 대한 질문도 필요하고, 그에 대해 이미 지난 글을 통해서 알아본 바 있습니다. ([패턴/객체지향] - 객체설계[3] - 객체지향 설계 원칙을 따르는 이유)
보통 '왜?'라는 질문에 대해서 이해가 되기 시작하면 그 다음 단계는 '어떻게?'라는 질문을 하게 됩니다. 오늘 배우실 객체지향 설계 원칙이 바로 이 '어떻게?'라는 질문에 대한 답이 되겠네요. 오늘은 그 원칙의 핵심을 먼저 알려드리겠습니다.
1. 설계의 목표를 파악한다. (재설계의 경우 재설계의 원인을 파악한다.)
2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.
3. 바뀌는 부분을 캡슐화한다.
끝입니다. 너무 간단한가요? 아니면 너무 추상적이라서 여전히 어떻게 해야할 지 감이 안잡히시나요? 원래 기본이라는 것은 쉬워보이지만 그 의미를 깨닫기까지 아주 많은 노력과 시간이 필요합니다. 앞으로 상세하게 알아볼 모든 내용이 이 3가지 원칙에서 거의 벗어나지 않습니다.
소개팅을 한번 예로 들어볼까요? 우리의 목표는 소개팅하는 과정을 표현하고, 그 결과를 boolean 값으로 나타낸다고 가정해보겠습니다.
1. 설계의 목표를 파악한다.
2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.
3. 바뀌는 부분을 캡슐화한다.
자, 어떠신가요? 조금은 이해가 되시는가요? 바뀌지 않는 부분인 절차적인 부분은 소개팅()에 구현이 되었고, 바뀌는 부분은 private 메서드로 빼서 상세한 내용을 기술하면서 소개팅()에서는 그 내용을 알 수 없도록 캡슐화한 것입니다.
캡슐화를 하는 방법은 다양합니다. private 메서드로 만들거나, 클래스로 만들거나, 인터페이스로 만듭니다. 아주 쉽게 말하면 블락( { ... } )안으로 감싸는 것입니다.
만약 캡슐화를 하지 않으면 다음과 같은 모양이 나옵니다.
두번째 예제가 더 좋아보일지도 모릅니다. 일련의 흐름이 하나의 메소드 안에 다 적혀있어서 그렇겠죠? 하지만 두번째 예제는 변경에 굉장히 취약한 구조를 가지고 있습니다. 소개받는 방법이 변경되어도, 또는 만나서 데이트하는 방법이 바뀌던지, 헤어지는 방법이 바뀌어도 소개팅()를 수정해야합니다. 그리고 수정해야 할 내용이 2개 이상만 되어도 소개받는 방법 때문에 소개팅()이 실패(false)하는지, 헤어지는 방법때문에 소개팅()이 실패하는지 알기 힘듭니다.
또한 소개팅()를 보는 사람은 [소개받음 -> 만나서 데이트 -> 헤어짐]으로 이어지는 큰 흐름을 파악하지 못할 가능성이 높아집니다. 이렇게 코드에 대한 가독성이 떨어지면 당연히 수정에 오래 걸리게 됩니다. 이해하는 시간이 그만큼 더 많이 필요하기 때문이죠.
단적인 예로 소개받음 부분이 50라인, 만나서 데이트하는 부분이 100라인, 헤어짐 부분이 50라인이라고 한다면 200라인을 한꺼번에 보시는 것이 이해하기 쉬우신가요? 아니면 3라인으로 흐름을 파악한 후 구체적인 각 절차를 따로 이해하시는 것이 이해하기 쉬우신가요?
하지만 개발자라면 이 '왜?'라는 질문을 적극적으로 하고, 스스로 답을 찾는 노력이 반드시 필요합니다. 마찬가지로 우리가 객체지향 설계 원칙을 따르는 이유에 대한 질문도 필요하고, 그에 대해 이미 지난 글을 통해서 알아본 바 있습니다. ([패턴/객체지향] - 객체설계[3] - 객체지향 설계 원칙을 따르는 이유)
보통 '왜?'라는 질문에 대해서 이해가 되기 시작하면 그 다음 단계는 '어떻게?'라는 질문을 하게 됩니다. 오늘 배우실 객체지향 설계 원칙이 바로 이 '어떻게?'라는 질문에 대한 답이 되겠네요. 오늘은 그 원칙의 핵심을 먼저 알려드리겠습니다.
1. 설계의 목표를 파악한다. (재설계의 경우 재설계의 원인을 파악한다.)
2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.
3. 바뀌는 부분을 캡슐화한다.
끝입니다. 너무 간단한가요? 아니면 너무 추상적이라서 여전히 어떻게 해야할 지 감이 안잡히시나요? 원래 기본이라는 것은 쉬워보이지만 그 의미를 깨닫기까지 아주 많은 노력과 시간이 필요합니다. 앞으로 상세하게 알아볼 모든 내용이 이 3가지 원칙에서 거의 벗어나지 않습니다.
소개팅을 한번 예로 들어볼까요? 우리의 목표는 소개팅하는 과정을 표현하고, 그 결과를 boolean 값으로 나타낸다고 가정해보겠습니다.
1. 설계의 목표를 파악한다.
public boolean 소개팅() {
...
}
2. 바뀌는 부분과 바뀌지 않는 부분을 파악한다.
바뀌지 않는 부분 : [1. 소개받는다. 2. 만난다. 3. 헤어진다.]로 이어지는 절차
바뀌는 부분 : 소개받는 방법, 만나서 데이트 하는 방법, 헤어지는 방법 등
3. 바뀌는 부분을 캡슐화한다.
public boolean 소개팅() {
// 1. 소개받는다.
소개받음();
// 2. 만나서 데이트한다.
만나서 데이트();
// 3. 헤어진다.
헤어짐();
}
private void 소개받음() {
// 소개받는 방법을 구체적으로 기술
...(친구를 괴롭혀서 강제로 소개해달라고 함)
}
private void 만나서 데이트() {
// 만나서 데이트 하는 방법을 구체적으로 기술
...(영화보고, 근사한 곳에서 저녁식사를 함)
}
private void 헤어짐() {
// 헤어짐
...(집까지 바래다주고, 애프터 신청을 정중하게 함)
}
자, 어떠신가요? 조금은 이해가 되시는가요? 바뀌지 않는 부분인 절차적인 부분은 소개팅()에 구현이 되었고, 바뀌는 부분은 private 메서드로 빼서 상세한 내용을 기술하면서 소개팅()에서는 그 내용을 알 수 없도록 캡슐화한 것입니다.
캡슐화를 하는 방법은 다양합니다. private 메서드로 만들거나, 클래스로 만들거나, 인터페이스로 만듭니다. 아주 쉽게 말하면 블락( { ... } )안으로 감싸는 것입니다.
만약 캡슐화를 하지 않으면 다음과 같은 모양이 나옵니다.
public boolean 소개팅() {
// 소개받는 방법을 구체적으로 기술
...(친구를 괴롭혀서 강제로 소개해달라고 함)
// 만나서 데이트 하는 방법을 구체적으로 기술
...(영화보고, 근사한 곳에서 저녁식사를 함)
// 헤어짐
...(집까지 바래다주고, 애프터 신청을 정중히 함)
}
두번째 예제가 더 좋아보일지도 모릅니다. 일련의 흐름이 하나의 메소드 안에 다 적혀있어서 그렇겠죠? 하지만 두번째 예제는 변경에 굉장히 취약한 구조를 가지고 있습니다. 소개받는 방법이 변경되어도, 또는 만나서 데이트하는 방법이 바뀌던지, 헤어지는 방법이 바뀌어도 소개팅()를 수정해야합니다. 그리고 수정해야 할 내용이 2개 이상만 되어도 소개받는 방법 때문에 소개팅()이 실패(false)하는지, 헤어지는 방법때문에 소개팅()이 실패하는지 알기 힘듭니다.
또한 소개팅()를 보는 사람은 [소개받음 -> 만나서 데이트 -> 헤어짐]으로 이어지는 큰 흐름을 파악하지 못할 가능성이 높아집니다. 이렇게 코드에 대한 가독성이 떨어지면 당연히 수정에 오래 걸리게 됩니다. 이해하는 시간이 그만큼 더 많이 필요하기 때문이죠.
단적인 예로 소개받음 부분이 50라인, 만나서 데이트하는 부분이 100라인, 헤어짐 부분이 50라인이라고 한다면 200라인을 한꺼번에 보시는 것이 이해하기 쉬우신가요? 아니면 3라인으로 흐름을 파악한 후 구체적인 각 절차를 따로 이해하시는 것이 이해하기 쉬우신가요?
선택은 여러분들의 몫입니다. ^^
'패턴 > 객체지향' 카테고리의 다른 글
| 객체설계[4] - 객체지향 설계 원칙(기본) (0) | 2011/11/13 |
|---|---|
| 객체설계[3] - 객체지향 설계 원칙을 따르는 이유 (0) | 2011/11/06 |
| 객체설계[2] - 소프트웨어 프로젝트 (0) | 2011/10/30 |
| 객체설계[1] - 소프트웨어의 목표 (4) | 2011/10/24 |
| 속성 값의 종류가 정해지지 않았을 때 (0) | 2009/03/09 |
| 집합 vs 구성 (0) | 2009/03/09 |
