5-2. 좋은 디자인 = 유연한 소프트웨어

OOA&D 도구 상자

요구사항

• 좋은 요구 사항은 시스템이 고객이 기대한 대로 동작하도록 합니다.
• 여러분의 요구 사항이 시스템의 유스케이스의 모든 단계들을 담고 있는지 확인하세요.
• 유스케이스를 사용해서 고객이 잊고 얘기하지 않았던 것들을 찾아내세요.
• 유스케이스는 시스템에 추가되어야 할 불완전하거나 빠진 요구 사항들을 분명하게 합니다.
• 요구 사항은 항상 끊임없이 변화합니다.(그리고 성장합니다.).

분석과 설계

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

 

객체지향 원리

• 변하는 것을 캡슐화하라.
• 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것이다.

 

* 응집도
 응집도는 하나의 모듈, 클래스, 또는 객체들을 이루는 원소들 사이에 연결의 정도를 나타냅니다. 여러분이 작성한 소프트웨어의 응집도가 높을수록, 여러분의 프로그램에서 각 클래스의 역할들이 잘 정의 되어있고 잘 연결되어 있는것입니다. 각 클래스는 밀접하게 연결되어 있는 하나의 매우 특정한 집합의 일들을 수행합니다.

 

핵심정리

• 보통 서브 클래스를 만드는 이유는 서브 클래스의 행동이 슈퍼 클래스와 다르기 때문입니다.
• 한 번 코딩하고 두 번 이상 보세요. 문제에 봉착할 때 여러분의 디자인을 계속 살펴보세요. 처음에 내린 디자인 결정이 지금은 여러분을 괴롭힐 수 있습니다.
• 자존심은 좋은 디자인에 방해됩니다. 많은 일을 다시 해야 하는 경우가 생길지라도, 여러분 자신이 채택한 디자인 결정 사항을 검토하고 향상시키는 것을 두려우워하지 마세요.
• 변경되는 것을 캡슐화하여, 프로그램을 더 유연하고 변경이 용이하게 만듭니다.
• 객체들 사이에 변하는 속성들이 있을 때, Map 같은 콜렉션을 사용해서 속성들을 동적으로 저장하세요. 새로운 속성들이 여러분의 클래스에 추가되어도, 메소드들을 추가하거나 코드를 변경할 필요가 없습니다.
• 대부분의 좋은 디자인은 나쁜 디자인의 분석을 통해 나옵니다. 실수하는 것과 변경하는 것을 절대 두려워하지 마세요.
• 응집된 클래스는 하나의 일을 정말 잘하고 그 외의 일은 하려고 하지도 않습니다.
• 모든 클래스는 변경에 대해 오직 하나의 이유만 갖도록 해야 합니다.
• 더 응집되어 있을수록, 클래스들간에 더 느슨한 결합을 갖게 됩니다. 기본적으로 프로그램을 수정하면 이미 응집되어 있고 느슨하게 결합되어 있는 설계를 변경해야 합니다.
• 여러분의 소프트웨어를 변경할 때마다 전점 응집도가 올라가는 지 확인하세요.
• 위대한 소프트웨어는 보통 충분히 좋으면 됩니다. 고객이 만족하는지 확인하세요. 디자인이 유연하게 하세요. 두 가지 일을 다 끝냈다면 다음으로 넘어갈 때입니다. 완벽한 소프트웨어를 작성하려고 많은 시간을 보내는 것은 시간 낭비입니다.