코드스피츠 오브젝트 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
참조로 참조할 수 있지만, 값 박쥐. 표현?
동시성 문제에서 자유로워짐.
확실하거나, 연산의 폭이 확실한 경우 값 객체를 고려해볼 수 있다.
값객체의 할당하는 필드가 절대로 외부에 노출하면 안됨