1장에서는 OOAD 관련해서 전체적인 OOAD 방법을 살펴 본다.
잘 설계된 소프트웨어 정의
1. 위대한 소프트웨어는 고객을 만족시켜야 합니다. 소프트웨어는 고객이 원하는 기능을 수행해야 합니다.
2. 좋은 소프트웨어는 잘 설계되어 있고, 잘 코딩되어 있고, 유지보수와 재사용, 그리고 확장이 쉽습니다.
쉬운 3단계로 위대한 소프트웨어 만들기
1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요
--> 요구사항 분석 및 수집, 기능 구현
2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요.
--> 중복코드 제거, 객체지향 방식을 제대로 적용했는지 확인
3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.
--> 디자인패턴과 원리를 적용하여 재사용이 쉽도록 수정
* 주의 : 문제를 해결하면서 새로운 문제를 만들지 마세요.
위의 1,2,3 단계는 소프트웨어가 제대로 기능하고, 잘 설계되고, 재사용이 용이하게
하는 쉬운 길을 제공합니다. 같은 목적을 달성하는 비슷한 방법이 있다면 그것 역시 좋습니다.
2번 단계로 가기 전에 1번 단계를 끝내는 것이 왜 중요한가?
프로그램이 제대로 동작하게 만들려면 그 프로그램을 여러 번 수정하게 될 것입니다.
기본 기능을 구현하기 전에 설계에 너무 신경을 쓰면 쓸데 없는 시간 낭비가 될 수 있습니다.
왜냐하면 여러분이 만든 클래스들과 메소드들에 새로운 기능을 추가할 때마다 설계의 많은
부분이 바뀌어야 하기 때문입니다.
잘 설계된 객체 만들기
1. 객체는 자신의 이름이 나타내는 일을 해야합니다.
객체가 비행기라고 명명되면, 아마 이륙하고 착륙해야 하지만 비행기표를 받지는 말아야 합니다.
2. 각 객체는 하나의 개념을 나타내어야 합니다.
객체가 두 개 이상의 임무를 맡지 말아야 합니다. 오리 객체가 꽥꽥거리는 오리,
노란 플라스틱 장난감 오리, 오리 같이 행동하는 사람의 세 가지 개념을 나타내는 것은 피해야 합니다.
3. 사용되지 않는 속성이 결정적 증거 입니다.
객체가 값이 없거나 null인 속성들을 가진 채로 사용되면, 객체가 하나 이상의 일을 하고 있을 가능성이 있습니다.
어떤 속성에 값이 없는 경우가 대부분이라면, 그 속성이 왜 그 객체의 속성에 있어야 합니까? 그 속성들의
일부만을 사용하는 더 좋은 객체가 있지 않을까요?
캡슐화
클래스에서 행위를 캡슐화 하는 경우, 클래스가 변하지 않고도 행위를 변경할 수 있습니다.
프로그램을 쪼개내어 다른 부분의 수정 없이 특정 부분을 변경할 수 있습니다.
일반적으로 프로그램 중에 변화 가능성이 높은 부분을 그렇지 않은 부분으로부터 분리하여
캡슐화하게 됩니다.
* 캡슐화를 통해 프로그램을 논리적 그룹으로 나눌 수 있습니다.
클래스 안의 데어터(data)를 프로그램의 행위(behavior)로 부터 분리하는 것처럼.
* 중복 코드를 볼 때마다 캡슐화 할 곳이 있는지를 찾아보세요.
위임을 왜 하는거죠?
기능을 여러 곳에 분산할 필요가 없습니다.
위임은 각 객체가 동일성을 스스로 해결하게 합니다. 즉, 여러분의 객체가 서로 독립적이고 더 느슨하게
결합되어 있는 것을 의미합니다.
핵심 정리
- 깨지기 쉬운 프로그램은 조금만 잘못 조작해도 문제가 발생합니다.
- 캡슐화와 위임 같은 객체지향 원리를 사용하여 유연한 프로그램을 만들 수 있습니다.
- 캡슐화는 프로그램을 여러 개의 논리적 부분들로 나눕니다.
- 위임은 특정한 일을 해결하는 책임을 다른 객체에게 주는 것입니다.
- 프로젝트는 항상 고객이 원하는 것을 알아내는 것부터 시작하세요.
- 프로그램의 기본 기능을 구현한 후에 설계를 유연하게 가다듬는데 노력하세요.
- 기능과 유연한 설계가 완성이 되면, 디자인 패턴을 사용해서 프로그램의 디자인을 개선하고, 재사용이 용이하게 만드세요
- 프로그램 중 자주 변경을 요하는 부분을 찾아서 변경되지 않는 부분과 분리해 놓으세요.
- 잘 동작하지만 설계가 엉망인 프로그램의 경우에 고객은 만족 시키지만 문제를 고치느라고 수고, 고통, 밤샘 등을 겪을 가능성이 큽니다.
- OOA&D는 고객과 프로그래머를 모두 만족시키는 좋은 설계를 갖춘 프로그램을 만드는 방법을 제공합니다.
'Programs > OOAD' 카테고리의 다른 글
5-2. 좋은 디자인 = 유연한 소프트웨어 (0) | 2012.09.22 |
---|---|
5-1. 좋은 디자인 = 유연한 소프트웨어 (0) | 2012.09.21 |
4. 분석 (0) | 2012.09.19 |
3. 요구사항 변경 (2) | 2012.09.18 |
2. 요구사항 수집 (4) | 2012.09.17 |