<헤드퍼스트 세상을 설계하는 객체지향 방법론> 요약

CHAPTER 1. 잘 설계된 프로그램이 세상을 뒤흔든다

• 객체지향 원리를 사용하여 유연한 프로그램을 만들 수 있다.
• 캡슐화는 프로그램을 여러 개의 논리적 부분들로 나눈다.
• 위임은 특정한 일을 해결하는 책임을 다른 객체에게 주는 것이다.
• 프로그램의 기본 기능을 구현한 후에 설계를 유연하게 가다듬는데 노력하라.
• 프로그램 중 자주 변경을 요하는 부분을 찾아서 변경되지 않는 부분과 분리해 놓으라.

CHAPTER 2. 요구 사항 수집

• 요구 사항은 시스템이 제대로 동작하기 위해 해야 할 일이다.
• 좋은 요구 사항들을 만들려면, 유스케이스를 만들어야 한다.
• 유스케이스는 시스템이 해야 할 일을 자세하고 명확하게 설명한다.
• 하나의 유스케이스는 하나의 목표를 가진다.
• 좋은 유스케이스는 시작 조건, 종료 조건, 외부 구동자, 사용자의 명확한 가치를 가지고 있다.

CHAPTER 3. 요구 사항 변경

• 요구 사항은 프로젝트를 진행하는 내내 계속 바뀐다.
• 대체 경로들은 가끔만 일어나는 단계들일 수 있고, 또는 유스케이스에서 부분적으로 완전히 다른 경로를 제공할 수도 있다.
• 거의 대부분 중복 코드는 피해야 한다.
• 중복 코드는 유지보수 할 때의 골칫거리이며, 보통은 시스템의 설계에 문제가 있다는 의미이다.

CHAPTER 4. 분석

• 분석을 하면 여러분이 만드는 소프트웨어가 여러분의 가상의 세계가 아니라 실세계에서 잘 동작하는지를 확인하는데 도움이 된다.
• 각 유스케이스는 고객의 하나의 목표에만 집중해야 한다.
• 여러 개의 목표를 가진다면, 여러 개의 유스케이스를 작성해야 한다.
• 클래스 다이어그램은 시스템과 코드의 구성 요소들을 한 눈에 볼 수 있게 하는 쉬운 방법이다.
• 클래스 다이어그램에서의 속성들은 보통 여러분이 만든 클래스의 멤버 변수에 매핑 된다.
• 클래스 다이어그램에서의 오퍼레이션들은 클래스의 메소드들을 나타낸다.
• 유스케이스의 명사들은 클래스 후보들이고, 동사들은 클래스의 메소드 후보들이다.

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

• 객체지향 원리
• 변하는 것을 캡슐화 하라.
• 구현에 의존하기 보다는 인터페이스에 의존하도록 하라.
• 한 클래스는 변경 요인이 오직 하나이어야 한다.
• 하나의 클래스는 하나의 일만을 해야 한다.

CHAPTER 6. 정말 큰 문제들 해결하기

• 큰 문제를 바라보는 가장 좋은 방법은 작은 문제들의 집합으로 보는 것이다.

CHAPTER 7. 아키텍처

• 아키텍처는 디자인의 구조이고, 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여준다.

CHAPTER 8. 디자인 원리들

• 디자인 원리는 코드를 좀 더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위해, 코드의 작성이나 디자인에 적용되는 기본 도구 또는 기법이다.
• #1 개방-폐쇄의 원리(Open-Closed Principle, OCP)
• 기존 코드를 변경하지 않으면서 코드의 수정을 허용하는 것
• 클래스는 확장에는 열려있고, 수정에는 닫혀 있어야 한다.
• OCP는 유연성에 대한 것이고 단순히 상속에 대한 내용이 아니다.
• OCP는 캡슐화와 추상화의 조합이다.
• #2 반복 금지의 원리(Don't Repeat Yourself, DRY)
• 공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하라.
• 하나의 요구 사항은 한 곳에 두어야 한다는 원리이다.
• 시스템의 각 정보와 기능을 말이 되는 하나의 장소에 두는 것을 의미한다.
• #3 단일 책임의 원리(Single Responsibility Principle, SRP)
• 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스를 그 하나의 책임을 수행하는 데 집중되어 있어야 한다.
• #4 리스코프 치환 원리(LSP)
• 자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다.
• 그렇지 않으면, 상속을 잘못 사용하고 있는 것이다.
• 다른 클래스의 기능을 사용해야 하지만 그 기능을 변경하고 싶지 않다면, 상속 대신 위임(Delegation)의 사용을 고려하라.
• 구성(Composition)에서는, 다른 행동들로 구성된 객체는 그 행동을 소유하고 있는 것이다.
• 그 객체가 없어지면 소유하고 있던 모든 행동들도 없어진다.
• 구성(Composition)에 참여한 행동들은 그 구성(Composition)의 외부에서는 존재하지 않는다.
• 집합(Aggregation)은 한 클래스가 다른 클래스의 부분으로 사용되지만 다른 클래스의 외부에서도 여전히 존재하는 경우를 지칭한다.
• 내가 사용하고 싶은 행동을 가지고 있는 객체가 그 행동을 사용하는 객체의 외부에서도 존재하나?
• 만약 객체가 독립적으로 존재하는 것도 의미가 있다면, 집합(Aggregation)을 사용해야 한다. 그렇지 않다면, 구성(Composition)을 사용하라.
• 클래스의 행동을 변경하고 싶지 않고, 그 행동을 스스로 구현하는 것이 그 클래스의 책임이 아닌 경우에는 그 행동을 다른 클래스에 위임(Delegation) 하라.
• 구성(Composition)을 사용하여 하나 또는 여러 개의 클래스, 특히 비슷한 종류의 여러 클래스들로부터 행동을 재사용할 수 있다. 여러분의 객체가 다른 객체를 완전히 소유하고 있는 형태이며, 구성(Composition) 관계로 연결된 객체는 여러분 객체의 외부에 독립적으로 존재할 수 없다.
• 구성(Composition) 관계의 이점을 바라지만 여러분 객체의 외부에서도 연결된 객체의 행동이 사용되는 경우, 집합(Aggregation)을 사용하라.

CHAPTER 9. 반복하기, 테스팅하기

• 프로그래밍 기술
• 약정에 의한 프로그래밍은 여러분과 소프트웨어 사용자가 지키기로 합의한, 소프트웨어가 어떻게 동작해야 하는지에 관한 계약을 설정한다.
• 방어적 프로그래밍은 다른 소프트웨어를 신뢰하지 않고, 다른 소프트웨어를 신뢰하지 않고, 다른 소프트웨어가 나쁘거나 안전하지 않은 정보를 제공하는지 확인하기 위해, 광범위하게 오류와 데이터를 점검한다.
• 개발 접근 방식
• 유스케이스 주도 개발은 시스템에서 하나의 유스케이스를 선정하여, 유스케이스의 모든 시나리오를 포함해서 그 전체를 구현하려고 코드 작업을 완성하는데 중점을 두고 있다. 그 다음에 애플리케이션의 다른 것으로 넘어간다.
• 특징 주도 개발은 하나의 특징에 집중하여 그 특징의 모든 행위 모두를 코드 작업한다. 그 다음에 애플리케이션의 다른 것으로 넘어간다.
• 테스트 주도 개발은 한 가지 기능의 테스트 시나리오를 작성하고, 그 다음에 그 기능에 대한 코드를 작성한다. 그리고 모든 테스트를 통과할 때까지 소프트웨어를 작성한다.
• 좋은 소프트웨어 개발 방법이란 대체로 개발 주기의 여러 단계에서 이러한 개발 모델 모두를 혼용한다.

CHAPTER 10. OOA&D 생명 주기

• 디자인 결정은 좋은 객체지향 원리뿐만 아니라 여러분의 시스템이 어떻게 사용될 것인가에 근거하고 있어야만 한다.
• 오직 상호작용할 필요가 있는 클래스만 고객에게 노출시켜야 한다.

부록.

• IS-A와 HAS-A
• IS-A는 상속을 말한다.
• 예를 들어 창은 무기이다. 그래서 창은 무기를 상속해야 한다.
• HAS-A는 구성(Compositioin)이나 집합(Aggregation)을 말한다.
• 유닛은 무기를 가지고 있다. 그래서 유닛은 무기 객체로 구성될 수 있다.
• IS-A 관계가 적용될 때보다는, 한 객체가 다른 객체처럼 행동할 때 상속을 사용해야 한다.
• 정사각형은 직사각형이지만 직사각형과 행동양식이 다르므로 정사각형이 직사각형을 상속하는 건 적합하지 않다.
• 상속은 다른 클래스를 기반으로 클래스를 만들게 하고, 중복되는 코드를 피할 수 있게 한다.
• 다형성은 상속과 밀접히 관련되어 있다. 다형성은 서브 클래스가 슈퍼 클래스를 대신할 수 있도록 허용한다.
• 캡슐화는 프로그래밍 요소들을 더 크고, 더 추상적인 엔티티 안에 감싸는 프로세스. 정보 은닉 또는 관심의 분리라고도 한다.