birdkr's home

  Head First Object-Oriented Analysis & Design 

브렛 맥래프린, 게리 폴리스, 데이빗 웨스트/한빛미디어
객체지향 개발 방법론은 소프트웨어의 정적인 데이터 측면과 동적인 기능 측면을 모두 중시한 시스템을 개발할 때 요구되는 여러가지 강력한 모델링 개념과 캡슐화 개념 등을 잘 지원하고 있다. 이러한 객체 지향...

 1장. 잘 설계된 프로그램이 세상을 뒤흔든다 - 위대한 소프트웨어는 여기에서 시작된다.

• 위대한 소프트웨어란?
  
  • 고객이 원하는 기능을 수행해야 한다.
  • 잘 설계되어 있고, 잘 코딩되어 있고, 유지보수와 재사용, 그리고 확장이 쉬워야 한다.

• 위대한 소프트웨어 만들기 3단계
  
  1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요. -> 일단 기능 구현
  2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요. -> 중복 코드 제거, 객체지향 방식 적용 확인
  3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요. -> 디자인 패턴과 원리를 적용

• OOA&D란?
  
  • 위대한 소프트웨어를 작성하는 방법에 관한 것이지, 방대한 문서 작업을 하기 위한 것이 아니다.
  • 고객은 프로그램이 동작할 때 만족스러워 한다. -> 유즈케이스와 다이어그램 보다는 잘 돌아가는 프로그램이 중요
  • 고객은 프로그램이 계속 잘 동작할 때 만족스러워 한다. -> 핵심은 잘 설계된 견고한 프로그램을 작성하는 것
  • 고객은 프로그램이 업그레이드가 가능할 때 만족해 한다. -> 캡슐화, 구성, 위임의 객체지향 기법을 사용하면 유지보수가 쉽고, 확장성이 좋은 프로그램을 만들 수 있다.
  • 프로그래머는 자신의 프로그램이 재사용될 수 있을 때 만족스러워 한다. -> 디자인 원리를 적용하여 복잡한 의존 관계와 연관 관계를 피하여 쉽게 재사용 가능하게 만들 수 있다.
  • 프로그래머는 자신의 프로그램이 유연할 때 만족스러워 한다. -> 리팩토링을 사용하여 좋은 프로그램을 다양한 종류의 일에 사용할 수 있는 훌륭한 프레임웍으로 바꿀 수 있다.
• 캡슐화의 개념은 프로그램 일부의 정보를 다른 부분으로부터 보호하는 것이다. 즉, 변경하는 것을 캡슐화하려는 노력이 항상 필요하다.

2장. 요구 사항 수집 - 그들에게 원하는 것을 주세요

• 요구 사항은 시스템이 올바르게 동작하기 위해서 수행하는 특정한 하나의 일입니다.
• 초기 요구 사항은 고객이 말해줍니다.
• 좋은 요구 사항들을 만들려면, 유즈케이스를 만들어야 합니다.
• 유즈케이스는 고객의 특정한 목표를 달성하기 위해 여러분의 시스템이 무엇을 하는지를 기술합니다.
• 좋은 유즈케이스는 시작 조건, 종료 조건, 외부 구동자(액터), 사용자의 명확한 가치를 가지고 있습니다.
• 여러분의 시스템은 모든 게 여러분의 기대대로 돌아갈 때가 아니라, 실제 상황에서 동작해야 합니다.

3장. 요구 사항 변경 - 당신을 사랑해요. 당신은 완벽해... 그런데 이건 좀 바꿨으면

• 소프트웨어를 개발할 때, 항상 변하지 않는 원칙이 하나 있다면? 요구 사항은 항상 변한다는 것.
• 요구 사항이 변하면, 시스템은 그 새로운 요구 사항을 해결하기 위해 변경되어야 합니다.
• 시나리오는 유즈케이스를 처음부터 끝까지 진행하는 하나의 경로입니다.
• 각 시나리오가 고객을 위해 같은 목표를 가지고 있기만 하면, 하나의 유즈케이스에는 여러 개의 시나리오가 있을 수 있습니다.
• 대체 경로들은 가끔만 일어나는 단계들일 수 있고, 또는 유즈케이스에서 부분적으로 완전히 다른 경로를 제공할 수도 있습니다.
• 거의 대부분 중복 코드는 피해야 합니다. 중복 코드는 유지보수 할 때의 골칫거리이며, 보통은 시스템의 설계에 문제가 있다는 의미입니다.

4장. 분석 - 여러분의 소프트웨어를 실제 세상으로...

• 분석을 하면 여러분의 시스템이 실세계에서 잘 동작하게 만들 수 있습니다.
• 유즈케이스를 여러분과 여러분의 상사, 여러분의 고객들이 이해하기 쉬운 방식으로 작성하세요.
• 분석과 유즈케이스들은 고객들, 관리자들, 그리고 동료 개발자들에게 여러분이 만드는 시스템이 실세계에서 어떻게 동작할 지를 보여줍니다.
• 위임은 여러분의 객체들을 다른 객체들의 구현 상의 변화로부터 보호합니다.
• 유즈케이스에서 사용되는 명사들이 대개는 시스템에서 작성하고 집중해야 할 클래스들입니다.
• 유즈케이스에서의 동사들은 대개 여러분의 시스템에서 색체의 메소드입니다.
• 클래스들과 메소드들을 찾아내기 위해 유즈케이스에서 명사(와 동사)를 분석하는 것을 본문 분석이라고 합니다.
• 잘 만든 유즈케이스는 시스템이 하는 일을 명확히 그리고 정확히, 이해하기 쉬운 언어로 설명합니다.
• 유즈케이스를 잘 만든 후에, 유즈케이스의 본문 분석을 통해 시스템에서 필요한 클래스들을 빠르고 쉽게 찾을 수 있습니다.
• 유즈케이스 안의 명사들이 여러분 시스템의 클래스가 되지 않더라도, 유즈케이스에서 명사들에 집중하세요.
• 여러분이 가지고 있는 클래스들이 어떻게 유즈케이스가 설명하는 시스템의 동작을 도와줄 수 있는 지를 생각해 보세요.

5장. 좋은 디자인 = 유연한 소프트웨어 - 변하지 않는 것은 없다

• 추상 클래스는 실제 구현 클래스를 위한 저장 장소입니다.
• 추상 클래스는 기능(behavior)을 정의하고, 그 기능은 서브 클래스가 구현합니다.
• 구현보다는 인터페이스에 의존하도록 코딩하는 것이 소프트웨어를 확장이 용이하게 합니다.
• 소프트웨어를 변경에 잘 견디도록 만드는 가장 쉬운 방법은 각 클래스가 변경의 이유를 하나만 갖도록 하는 것입니다.
• 한 번 코딩하고 두 번(아니 그 이상) 보세요. - 문제에 봉착할 때 여러분의 디자인을 계속 살펴보세요. 처음에 내린 디자인 결정이 지금은 여러분을 괴롭힐 수 있습니다.
• 대부분의 좋은 디자인은 나쁜 디자인의 분석을 통해 나옵니다. 실수하는 것과 변경하는 것을 절대 두려워하지 마세요.
• 응집된 클래스는 하나의 일을 정말 잘하고 그 외의 일은 하려고 하지도 않습니다.
• 모든 클래스는 이것에 대해 오직 하나의 이유만 갖도록 해야 합니다.
• 보통은 행동(behavior)이 변하는 경우에 서브 클래스를 사용하세요.
• 위대한 소프트웨어는 보통 충분히 좋으면 됩니다. - '완벽한 소프트웨어'를 작성하려고 많은 시간을 보내는 것은 시간 낭비입니다.
• '충분히 좋아' 라고 생각될 때 - 고객이 만족, 디자인이 유연
• 좋은 디자인의 목표 -> 응집도가 높고, 느슨하게 결합된 소프트웨어

6장. 정말 큰 문제들 해결하기 - "내 이름은 아트 반델리... 나는 건축가예요"

• 작은 문제를 푼 것과 똑같은 방식으로 큰 문제도 해결합니다. -> 위대한 소프트웨어 만들기 3단계
• 큰 문제는 여러 개의 기능별 조각들로 나누고 각 조각들을 개별적으로 풀어감으로써 해결할 수 있습니다.
• 고객으로부터 시스템의 특징들(feature)을 얻어내고 나서, 그 특징을 구현하기 위해 필요한 요구사항들을 알아내세요.
• 항상 세부 내용은 늦출 수 있을 때까지 최대한 늦추세요. - 유즈케이스는 개발 시스템 전체의 큰 그림을 보는데 도움이 되지 않습니다.
• 도메인 분석을 통해 디자인을 확인할 수 있고, 고객이 사용하는 용어를 사용할 수 있습니다.

7장. 아키텍처 - 혼란스러운 세상에 질서를

• 아키텍처는 디자인의 구조이고, 프로그램의 가장 중요한 부분들과 그들 사이의 관계를 명확히 보여줍니다.
• 시스템의 본질은 가장 기본적인 수준이 완성되었을 때의 시스템 모습입니다.
• 프로젝트의 아키텍처 설계 단계에서 하는 모은 일은 프로젝트 실패의 위험을 줄여야 합니다.
• 프로젝트에서 위험을 줄이려면, 한 번에 하나의 특징에 집중하세요. 위험을 줄이는 데 도움이 되지 않는 특징들에 너무 신경쓰지 마세요.
• 좋은 디자인은 항상 위험을 줄여 줍니다.

8장. 디자인 원리들 - 독창적인 디자인은 정도껏

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

9장. 반복하기, 테스팅하기 - 소프트웨어는 여전히 고객을 위한 것입니다

• 큰 그림을 그리고, 그 다음 애플리케이션이 완성될 때까지 조각조각들에 대해 반복적으로 작업하세요.
• 반복 작업의 두 가지 접근 방식
  
  • 특징 주도 개발(Feature driven development) - 애플리케이션의 특정한 특징을 선택하고, 완성될 때까지 그 특징을 계획, 분석, 개발하는 것입니다.
  • 유즈케이스 주도 개발(Use case driven development) - 유즈케이스의 시나리오를 선택하여 시나리오가 완성될 때까지 코드를 작성하는 것입니다.
• 테스트 주도 개발(TDD)은 클래스의 기능을 올바르게 만드는 데 집중합니다.
• 좋은 테스트 케이스는 오직 기능의 특정 부분 하나만 테스트합니다.
• 약정(contract)에 의한 프로그래밍은 트랜잭션의 양쪽 대상이 무슨 행동이 무슨 행위를 발생시키는지 알고 있다는 가정하에 약정을 지키는 것입니다.
• 방어적 프로그래밍은 잘못될 것들을 찾아서, 문제 상황을 회피할 수 있도록 폭넓게 테스트합니다.

10장. OOA&D 생명 주기 - 종합하기

• OOA&D 스타일로 소프트웨어 개발하기
  
  1. 특징 리스트 - 상위 수준에서 애플리케이션이 어떻게 동작되어야 하는지 이해하기
  2. 유즈케이스 다이어그램 - 애플리케이션이 수행할 프로세스와 관련된 외부 영향을 결정 하기
  3. 문제점 분해하기 - 애플리케이션을 기능 단위의 모듈들로 분해하여, 각 모듈 중 어떤 것을 먼저 다룰지 순서를 결정하기
  4. 요구 사항 - 각 모듈에 대한 개별적 요구 사항을 이해하고 큰 그림에 부합하도록 만들기
  5. 도메인 분석 - 어떻게 유즈케이스들이 애플리케이션의 객체들로 사상되는지를 이해하고, 고객과 공감대 형성하기
  6. 사전 설계 - 객체들에 대한 세부 내용을 채워 넣고, 객체들 사이의 관계를 정의하며, 원리와 패턴을 적용하기
  7. 구현 - 코드를 작성하고, 테스트하여, 동작하는 것을 확인하기. 완성할 때까지 각 행위, 각 특징, 각 유즈케이스, 각 문제점에 대해 그렇게 하기
  8. 4부터 7까지 반복적으로 개발
  9. 출하 - 완성! 소프트웨어를 발표하고, 송장을 제출하고, 돈 받기
• 위대한 소프트웨어 만들기
  
  • 1~5 : 여러분의 소프트웨어가 고객이 원하는 기능을 하도록 하세요.
  • 6~7 : 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요.
  • 7 : 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.

이 글은 스프링노트에서 작성되었습니다.