[켄트벡의 구현패턴] ~80p

1. 소개

2. 패턴

• 프로그래밍에 있어 공통적인 문제를 해결하는 것이 비용이 적게 듬.
• 이를 통해 프로그래머가 독창적인 문제 해결에 더 집중할 수 있게 해준다.
• 가능하게 해주는 것이 바로 '패턴' -> 일종의 바둑의 '기보' 같은 거라고 이해함.

3. 프로그래밍 이론

• 가치
  - 커뮤니케이션 -> 코드를 쉽게 이해할 수 있을 때, 커뮤니케이션 한다고 함.
  - 단순성 -> 복잡도가 낮은 것. (독자의 수준에 따라 조금 다름. 초보가 어렵다고 보는 걸 고수는 쉽다고 느낄 수 있음)
  - 유연성 -> 확장이나 수정에 있어서 유연한 정도 (유연성은 복잡도를 증가시키기도 함)
• 원칙
  - 가치는 프로그래머별로 중점을 두는 부분이 달라질 수 있으나, 원칙은 정해진 것.
  - 가치로 따져서 패턴을 결정하기 어려울 때(모호할 때) 원칙에 따라 결정할 수 있음.
  - 지역적 변화, 최소중복, 로직과 데이터의 결합, 대칭성, 선언적표현, 변화율 <- 추후 다시 읽어볼 것

4. 동기유발

• 코드는 개발당시보다 유지보수 할 때의 비용이 더 크다.
• 구현 패턴을 통해 개발 속도도 높이고, 유지보수 비용도 줄일 수 있다. -> 고로 패턴을 익혀서 쓰자

5. 클래스

• 클래스 - 데이터와 연관된 로직을 함께 표현할 때 사용
• 단순한 상위 클래스 이름 - 최상위 클래스 이름은 단순하게 짓는게 좋다.
• 한정적 하위 클래스 이름 - 상위 클래스와 다른 하위 클래스의 특징을 표현한 이름이 좋다.
• 추상 인터페이스 - 인터페이스(추상화된 일종의 껍데기) 부분과 구현 부분을 분리.
• 인터페이스 - 자주 변하지 않는 인터페이스는(클래스에 기능 추가 되지 않는 경우) 자바 인터페이스를 사용하는 것이 좋다.
• 버전 인터페이스 - 인터페이스가 추가되는 등의 변경이 있을 경우 인터페이스를 상속받아서 하위(버전)인터페이스 생성으로 처리가능. (but, 좋은 방법은 아니다. 알고는 있자 정도..)
• 추상 클래스 - 자주 바뀔 것 같은 인터페이스 구현시에는 추상 클래스로 구현하기.
• 값 객체 - 프로시져 형태 구현(순차선언 및 실행)이 아닌 산술값처럼 동작하는 객체를 사용하자.
• 특화 - 관련 연산 사이의 유사점/차이점을 분명히 나타냄.
• 하위 클래스 - 1차원적 변화는 하위 클래스를 사용하여 표현.
• 구현자 - 연산 내용이 바뀌었으면, 기존 메소드 오버라이드로 구현
• 내부클래스 - 보통 클래스 내부에서만 사용할 로직을 전용클래스로 구현
• 인스턴스별 행동 - 인스턴스 생성 후에는 인스턴스의 행동을 변화시키지 않는 것이 좋음.
• 조건문 - 인스턴스별 행동을 다르게 줄 수 있는 기본적인 형태이나, 조건문 분기별(수행경로) 오류 발생 가능성이 높아 좋지 않다.
• 위임 - 조건문의 단점을 극복하기 위한 방법 중 하나, 여러 종류의 객체 중 하나에 현재 메소드의 책임을 위임해서 처리하게 해줌.
• 플러그인 선택자 - 위임과 마찬가지. 리플렉션을 이용한 메소드 호출로 하나의 메소드로 여러 로직을 처리 가능. (but, 좋지 않은 방법)
• 익명 내부 클래스 - 필요 메소드에서 한 두개의 메소드만 오버라이드 객체를 만들어서 사용.
• 라이브러리 클래스 - 마땅히 들어갈 곳 없는 기능들을 묶어서 정적 메소드로 표현. (ex. 유틸 클래스)