자바 패키지

바이너리 컴포넌트

패키지 설계의 원칙들

패키지 릴리스 / 재사용 등가 원칙

• 재사용할 때 같이 몰려다니는 클래스들은 한 패키지로 묶어 놓는다.
• 재사용의 가장 작은 단위는 릴리스의 가장 작은 단위다

공통 폐쇄 우너칙

• 만약 어떤 것으를 변경해야 한다면, 그것 때문에 바꾸어야 할 클래스들이 한 패키지에만 몰려 있기를 원한다.

공통 재사용 법칙

• 한 클라이언트가 사용하는 클래스들과 다른 클라이언트가 사용하는 클래스들은 최대한 분리해야 한다.
• 서로 다른 클라이언트가 사용하는 클래스들이 한 패키지에 섞여 있을 경우, 패키지 않의 어떤 클래스를 바꾸면 그 변경된 클래스를 사용하지 않는 패키지들까지 그 변화의 영향을 받을 수 있다.

의존 관계 비순환 원칙

안정된 의존 관계 원칙

안정된 추상화 원칙

결론

• dX의 실천 방법 가운데 핵심은 모든 것을 짧은 주기로 반복
• 요구사항, 분석, 설계, 구현, 테스팅, 문서화 모든 것을 짧은 주기 반복
• 짧은 주기는 한 주 또는 두 주를 의미
• 주기마다 계획을 짜며 시작하고 고객에게 전달할 만한 결과물을 만듦으로서 주기를 종료

최초의 탐사 작업

• 첫 번째 주기는 종료할 때 코드가 없어도 되며 유일하게 두 주보다 짧아도 된다.
• 상세한 요구사항을 포착하는 시기가 아니다.
• 단지 시스템의 범위에 대해 아이디어를 얻으려는 것뿐
• 유스케이스를 찾아낸다.
• 유스케이스를 인덱스 카드에 한장에 하나씩 적어 놓는다.
• 이 카드를 사용자 스토리라고 부른다.
• 이 카드에는 유스케이스의 자세한 내용은 빼고 유스케이스의 이름만 적는다.
• 이 탐사는 끝나지않는다. 새로운 요구나 기능을 논의하고 스토리를 기록한다.

각 기능의 추정치 잡기

• 프로그래밍을 위한 하루라는 개념을 써서 추정할 수 있다.

• 프로그래밍을 위한 완벽한 하루

  • 적절한 시간에 잠자리에 들고
  • 아침식사도 배불리 먹고
  • 일하러 오는데 교통체증도 없었고
  • 하루종일 전화도 걸려오지 않고
  • 회의도 없고
  • 컴퓨터가 한 번도 다운되지 않고
  • 네트워크 속도는 무한에 가까울만큼  빠르고
  • 직장동료는 똑똑하고 인내심 있고 잘 배려 해주는 사람들

스파이크

계획짜기

릴리스 계획하기

반복 주기를 계획하기

중간 지점

결과를 속도에 반영하기

반복 주기를 관리 단계로 조직하기

반복 주기에서는 어떤 일이 일어나는가?

짝을 이뤄 개발하기

인수 테스트

단위 테스트

• 하루에 몇 십개
• 한 주에 몇 백개
• 한달이면 몇 천개가 쌓인다.
• 특정한 API 함수를 호출하는 방법을 알고 싶다면, 그것을 테스트가 있으니 보면 된다.

리팩토링

• 시스템의 동작에는 변화 없이 프로그램의 구조만 개선하는 행동
• 하루 일을 마칠 때 나쁜 코드를 남기지 않는 것을 규칙

개방된 작업 공간

끊임없는 통합 작업

• 락을 걸지 않는 소스 컨트롤 시스템을 사용
• 체크 인도 먼저 체크 인한 사람이 임자
• 체크 인한 사람이 처음 사람의 코드를 자신의 코드와 합쳐야 한다.
• 모듈을 체크 아웃해놓은 시간이 길면 길수록 코드를 합쳐야 할 가능성도 커진다.
• 빨리 자주 체크 인해야 한다는 압력이 생기며, 이것은 좋은 현상이다.
• 체크 인을 하기 전 반드시 모든 단위 테스트와 인수 테스트를 통과함을 보여야 한다.

결론

• UML은 방법론이 아니라 표기법이다.
• 자바도 방법론이 아니라 프로그래밍 언어다.
• 이런 표기법과 언어는 필요할 때 사용하면 그만이다.
• 의무적으로 작성하는 문서는 대부분 그다지 쓸모가 없다
• 여러분에 당장 필요하고 중요한 문서만 만들어라
• UML 다이어그램 그리기가 필수는 아니라는 뜻이다.

dX 는 거꾸로 읽으면 XP 이다. 저자의 센스

설계의 품질

• 잘 설계 된 시스템은 이해하기 쉽고, 바꾸기도 쉽고, 재사용하기도 쉽다.
• 개발하는데 특별히 어렵지도 않고, 단순하고 간결하며 경제적이다.
• 잘 설계 시스템을 개발하는 일은 즐겁다.

나쁜 설계의 냄새

1. 경직성: 무엇이든 하나를 바꿀 때마다 반드시 다른 것도 바꿩야 하며, 그러고 나면 또 다른 것도 바꿔야 하는 변화의 사슬이 끊이지 않기 때문에 시스템을 변경하기 힘들다.
2. 부서지기 쉬움: 시스템의 한 부분을 변경하고 나면 그것과 전혀 상관없는 다른 부분이 작동을 멈춘다.
3. 부동성: 여러 컴포넌트로 분리해서 재상요하기 힘들다.
4. 끈끈함: 편집-컴파일-테스트 순환을 한 번 도는 시간이 엄청길다.
5. 쓸데없이 복잡함: 필요없는 반복: copy - paste 같다.
6. 투명함: 코드를 만든 의도에 대한 설명을 볼 때 그 설명에 "표현이 꼬인다"라는 말이 어울림

의존 관계 관리하기

단 하나의 책임 원칙(The Single Responsibilty Principle - SRP)

• 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
• 클래스는 오직 하나만 알아야 한다.
• 오직 하나의 책임만 져야 한다.
• 더 핵심적인 말로 바꿔보면, 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

개방-폐쇄 원칙(The Open-Closed Principle - OCP)

• 소프트웨어 엔티티(클래스, 모듈, 함수 등등)는 확장에 대해서는 개발되어야 하지만, 변경에 대해서는 폐쇄되어야 한다.

리스코프 교체 원칙(Liskov Substitution Principle - LSP)

• LSP를 지키지 않았다는 말은 곧 OCP도 지키지 않았다는 말이다.

의존 관계 역전 원칙(Dependency Inversion Principle - DIP) 

• 고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.

• 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.

  • 자주 변경되는 컨크리트 클래스에 의존하지 마라
  • 어떤 클래스를 상속받아야 한다면, 기반 클래스를 추상 클래스로 만들어라
  • 어떠 클래스 참조를 가져야 한다면, 참조 대상이 되는 클래스르르 추상 클래스로 만들어라.
  • 만약 어떤 함수를 호출해야 한다면, 호출되는 함수를 추상 함수로 만들어라

인터페이스 격리 원칙(Interface Segregation Principle - ISP)

• 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다.

결론

유스케이스는 훌륭한 아이디어로 시작했지만 나중에 괜히 엄청나게 복잡해진 경우다.

유스케이스를 단순하게 유지하는 것이 유스케이스를 사용하는 진짜 비결이다.

정해진 형식을 맞춰야 하나 걱정하지 말고 그냥 빈 종이에 쓰거나, 단순한 워드프로세서로 빈페이지에 작성하거나, 텅빈 인덱스 카드에 적어라

모든 세부사항을 채워야 하는지 걱정할 필요도 없다.

세부사항은 나중에 중요해진다.

모든 유스케이스를 포착할 수 있는지 걱정하지도 마라. 애초에 불가능한 일이다.

기억해야 할 점은 이것이다. "내일이면 다 바뀐다." 내일이면 다 변한다.

유스케이스를 그때그때 작성하는 요구사항이라고 생각하라

유스케이스 적기

• 특정한 관점에서 보는 시스템의 동작을 글로 기술 한 것이다.

• 유스케이스 다이어그램은 유스케이스의 내용은 하나도 말해주지 않는다.

• 유스케이스 다이어그램들에는 유스케이스가 포착해야 하는 동작상의 요구사항에 관련된 정보는 하나도 없다.
  

유스케이스란 무엇인가?

• 유스케이스는 시스템의 동작 하나를 기술

• 사용자가 보낸 자극 하나에 대한 반응로 시스템이 진행하는 눈에 보이는 이벤트들의 흐름을 포착
  

기본흐름

• 유스케이스를 구성하는 항목의 첫 째 항목은 "흐름"이다.

• 세부사항을 기록하지 않을 것이다.

• 만약 세부사항을 하나도 기록하지 않는다면 어떻게  유스케이스를 추정해볼 수 있을까? 그것은 skateholder와 이야기해보면 추정할 수 있다.

• 세부사항을 너무 일찍 기록하는 작업은 비용 대비 효율이 너무 낮다

• 무엇을 기록할까?

• 유스케이스 이름을 기록하라

• 구현할 때가 가까워지면 세부사항을 채워 넣는다.
  

대체흐름

• 대화할 때 여러분은 실패 시나리오를 이야기해봐야 한다. ("프로젝트 실패가 아닌 not condition을 말하는 것 같다.")
  

나머지는?

• 액터, 2차 액터, 선행조건, 후행조건 등등은 알 필요가 없고

• 더 자세히 알고 싶으면 Alistair Cockburn - Writing Effective Use Cases 를 읽으면 된다.

유스케이스 다이어그램

• 유스케이스 다이어그램은 UML의 많은 다이어그램에서 가장 혼란스럽고 쓸모없다.
  

시스템 경계 다이어그램

• 유스케이스 다이어그램은 프로젝트 이해당사자에게 프리젠테이션할 때 멋진 표지로 사용하기에는 좋다.
  

유스케이스 관계

결론

기본개념

• 객체, 생명선, 메시지 등등
• 생성과 소멸
• 단순한 반복
• 사례와 시나리오

고급개념

• 반복과 조건
• 시간이 걸리는 메세지들
• 비동기 메세지
• 다중 쓰레드
• 활동적인 객체
• 인터페이스에 메세지 보내기
  

결론

• 개발자가 코드를 작성하기 전에 모든 메소드의 시퀀스 다이어그램을 그려야 한다는 생각은 1990년대의 소프트웨어 개발 방법론에서 가장 큰 오류다
• "항상 이책은 핵심적인 부분만을 그리기를 원하고 소통의 도구로서 빨리 그릴 수 있는 환경을 원한다. UML이 많은 것보다 적은것이 좋다고 한다. 나는 이 사람이 유명한 사람인지 몰랐다. 로버티 C 마틴.... 거의 OOAD 계의 거장이다. "

• 클래스 다이어그램은 굉장히 유용하다.
• 의존관계의 구조를 명확하게 볼 수 있게 해누며
• 순환 의존이 발생하는 지점을 찾아내서 어떻게 이 순환 고리를 깨는 것이 가장 좋은지 결정할 수 있게 해준다.

1. 기본

   • 클래스

     • 클래스에 세부사항을 자세히 적는 것이 유용할 때도 있지만, 자주 이렇게 해서는 안된다. 차라리 그런 것은 코드에서 하는 것이 더 낫다.

   • 연관

     • 대개 다른 객체의 참조를 가지는 인스턴스 변수를 의미한다.
     • hasa, isa 를 사용하지 말자. 해깔리고 논쟁의 대상이 될수 있다. 아싸리 "...와 연결이 된다" 표현이 더 낫다고 한다.

   • 상속

     • 화살촉 그릴 때 유의
     • 연관과 구분해야 함
     • 하지만 인터페이스까지 구분하기에는 에너지 낭비가 심하니까 근야 무시해도 됨

2. 예제 클래스 다이어그램

   • 중요한 부분만 다이어그램으로 표현하고 세부사항도 마찬가지
   • 연관은 가로로 표시하고 상속은 세로로 표시하므로서 구분하는데 큰 도움이 된다.

3. 세부사항

   • 클래스 스트레오타입

     • 자바 프로그래머가 사용할 만한 두가지는 <<interface>>와 <<utility>> 이다.
   • 추상 클래스
   • 프로퍼티

   • 집합

     • 아래 합성과 함께 전혀 사용하지 않으며 여러분도 피했으면 좋겠다.
   • 합성
   • 다수성
   • 연관 스트레오타입
   • 내부 클래스
   • 익명 내부 클래스
   • 연관 클래스
   • 연관 한정사

4. 결론

   • 최소한 사용이 이해하기 쉽다. 그래서 UML을 너무 적게 사용하는 편이 너무 많이 사용하는 것보다 낫다.

UML의 주요 다이어그램 세 종류

• 정적 다이어그램: 클래스, 객체, 데이터 구조와 이들의 관계
• 동적 다이어그램: 시퀀스, 상태
• 물리적 다이어그램: 소스 파일, 라이브러리, 이진파일, 데이터 파일
  

• 다이어그램의 종류에 대한 설명

  • 클래스 다이어그램
  • 객체 다이어그램: 메모리 상태를 표현
  • 시퀀스 다이어그램: 메시지를 보내고 받고 하는 정보의 흐름
  • 협력 다이어그램: 시퀀스와 비슷하게 흐름을 가지고 객체 사이의 관계를 명확히 하기 위해 사용한다. 2장 예제 참조
  • 상태 다이어그램

1. 위의 다이어그램만 알아도 대부분의 목적을 달성할 수 있고, 대부분의 프로그래머는 위에서 말하는 UML 지식 정도만 가지고 충분히 잘 살아갈수 있다.