코드스피츠 오브젝트 83 #3

## 메모리 주소의 별명

Type

데이타 타입에 대한 이야기
형

Types

Role : 형을 통해 역할을 묘사함
Responsibility : 형을 통해 로직을 표현
Message : 형을 통해 메시지를 공유
Protocol : 객체간 계약을 형을 통해 공유함

마커인터페이스 : 몸체가 없지만 형..

## static, enum, class

static : 단 한개의 인스턴스가 존재 (동시성 문제를 해결해야 함)
enum : 제한된 수의 인스턴스가 존재 (제너릭에 사용불가없음)
class : 무제한의 인스턴스 존재

enum 은 JVM이 기술되어있는 인스턴스를 만들고 시작. static 초기화 보다 더 빨리.

static 은 factory 이거나 상태갖지 않는 유틸리티

유틸리티 함수와 메서드 구분
this 가 없다면 유틸리티
라이프사이클, this 가 있다면 메서드

유틸리티 함수의 특징. 인자와 지연변수를 가지고 혹은 전역적인 컨텍스트만 가지고 짜여진 경우
클래스인스턴스는 오직 this 컨텍스트와 관련된


## condition

1. 조건분기는 결코 제거할 수 없다.
2. 조건 분기에 대한 전략은 두가지 뿐이다
- 내부에서 응집성 있게 모아두는 방식
 장점: 모든 경우의 수를 한 곳에서 파악할 수 있다
 단점 : 분기가 늘어날 때마다 코드가 변경된다. 
 - 외부에 분기를 위임하고 경우의 수 만큼 처리기를 만드는 방식
 장점 : 분기가 늘어날 때마다 처리기만 추가하면 된다. 
 단점 : 모든 경우의 수를 파악할 수 없다.

 

cohesion 과 injection 차이 그림

장점
1) 클라이언트 코드와 유틸리티코드 
if의 변화를 클라이언트 코드가 가져가게 하는것이 목적

2) 
라이브러리가 if 가 있을 때는 라이브러리가 확정할 수 없지만..injection 방식은
변화하기 쉬운 무기의 변화는 외부에서 만들어서 공급

Responsibility Driven
value = responsibility 
책임 = 가치
시스템의 존재 가치는 사용자에게 제공되는 기능
사용자가 사용할 기능 = 시스템의 책임
시스템 차원의 책임을 더 작은 단위의 책임으로 분할
해당 책임을 추상화하여 역할을 정의함
역할에 따라 협력이 정의됨

책임과 역할은 따로다...
좋은 개발자의 원천 회사의 비즈니스를 좋아하느냐 안 좋아하느냐.. 에 따라 또 달려있다. 

 

지난시간의 모델

Export 패턴 : 전문가 패턴
정보 전문가에게 책임을 부여하는 것이 제일 낫다.
객체의 특성
자기의 상태를 외부에 노출하지 않는 것이 기본. 
최대한 노출하지 않으면서 가장 업무가 있는 녀석.. => Screening.
정보 전문가패턴

시스템의 정보가 제일 많이 알고 있는 애들이 그래.
우리가 알고 있는 현실의 정보는.. 정보와 책임이 일치하지 않음
팀장이 제일 개발 잘하는거 아니잖아.
사장이 비즈니스 로직 제일 잘 아는거 아님. 
정보 전문가 패턴의 단점.

실제로 짜보면 또 그렇게 안됨. 
스크리닝이 예약을 갖는 이유.. 
상영이 예매를 한다는게 말이 됨?
쓸 때 안 쓸때를 구별해서 써야함.

상영이라는 것은 여러 영화가 공유할 수 있는거 아님?
=> 스크리닝은 시간만 있으면 되는거 아님?
10시 인디아나존스, 10시 스타워즈 객체가 필요한가?!

어떤 객체가 정말 두개가 만들어야하는지..고민.

RDB 의 정규화가 객체지향에서 역할과 책임을 분리할 떄 어디까지를 얘의 아는 정보로 분류할 수 있음
스크리닝은 리저브를 받기에 적합하지 않다.

DiscountCondition : 언제
DisccountPolicy : 어떻게 해줄까요

 

무비는 컨디션

 

 

무비의 속성을 소화하는 것은 

Movie 의 상수값 타입, 객체간에 분리시켜야하는 것을 무비의 속성

단 하나의 타입 조건. 값, 객체말고 형으로 인식
AmountDiscount 라는 타입을 갖는 무비

사실은 영화가 가격을 가지면 안되


값은 더 이상 확장이 불가능하다. 
객체는 포인터의 포인터이기 때문에 반응할 수 없다.


어떻게 하면 인자가 없는 함수
두번째로 좋은 함수 : 인자가 하나받는 함수
모든 인자를 추상화해서 객체 하나에 받는 함수

제일 좋은 인터페이스
메서드 정의가 아무것도 없는 것. Closeable 정도만 마킹

implement inversion

값에 의존해서 객체를 식별하지 마라. List(X) Set(O)

--- 
역할
책임은 외부에 수행해야할 메서드
권한은 내가 알아야하는 것

## Value Object

참조로 참조할 수 있지만, 값 박쥐. 표현?
동시성 문제에서 자유로워짐.
확실하거나, 연산의 폭이 확실한 경우 값 객체를 고려해볼 수 있다. 

값객체의 할당하는 필드가 절대로 외부에 노출하면 안됨