ch1

책임의 이동.
그냥 가장 편하게 절차 지향적으로 짰을 때 생기는 문제는
모든 책임이 다 하나의 main함수에 집중된다는 점입니다.

이때 객체지향을 제대로 적용한다면, 제대로 라는게 clean architecture 기준으로 domain 레이어가 무거워지는, Rich Domain을 보여주는 정석이라고 생각합니다

또 중요한 개념이 1장에서 나오게 되는데요
너무 다 옮기려고 하다보면, 결국 의도하지 않았던 의존성이 추가되곤 합니다. 이때는 결합도와, 도메인 객체의 자율성 이 2가지를 보고 trade off가 발생합니다.
이러한 tradeoff를 잘 만들어 내는 것이 좋은 설계이지, 100%완벽한 설계는 존재하기 불가능합니다.

Theater같은 것도, 현실에서는 판매원이, 그냥 티켓을 팔아버리지만, 프로그래밍의 세계에서는 이 Theater같은 것들을 살아있는것처럼 의인화를 시켜주는 것을 통해 프로그래밍이 생동감 있는 느낌으로 진행된다.

설계란 코드를 배치하는 것
애플리케이션의 기능을 구현하기 위해, 객체들이 협력하는 과정 속에서 객체들은 다른 객체를 알고 있어야 하는데, 이를 의존성이라고 한다

ch2

영화, 상영을 구분한다. 영화는 영화에 대한 데이터
상영은 영화, 상영 일자, 순번을 포함한다
할인 조건과 할인 정책에 의해 할인 된다
할인 조건은 순서조건과 기간조건
순서 조건=> 매일 10번째 영화 예매자 할인
기간 조건 : 조조 영화 할인

할인 정책은 할인 금액을 결정한다.
금액 할인과 비율 할인을 의미한다

객체 지향을 생각 할 때, 어떤 클래스 부터 결정하는 것이 아니라, 어떤 객체들이 필요한 지 고민 해야 한다
클래스는 객체를 추상화 한 것이다
객체를 독립적인 존재가 아니라, 기능을 구현하기 위한 공동 협력자로 생각한다.
훌륭한 협력이 훌륭한 객체를 만들고, 훌륭한 객체는 훌륭한 클래스를 만든다

도메인을 고려해야 한다.
소프트웨어는 사용자가 원하는 무언가를 해결하기 위해 만들어진다.
문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 부른다
이처럼 문제를 해결하기 위해 사용자가 프로그램을 사용하려는 분야를 도메인이라고 한다

객체지향 패러다임이 강력한 이유는 요구사항을 분석하는 처음부터, 마지막 단계까지 동일한 추상 기법을 사용할 수 있어서 이다.
가장 먼저 db 설계 하는 것처럼 one to one, one to many, 같은 관계를 미리 생각해두고 가면 그 자체가 객체가 될 수 있다.

인스턴스 변수는 private이고, 메서드는 public이다. 경계의 명확성이 경계의 자율성을 보장한다
=> 구현의 자율성을 보장한다

객체가 상태와 행동을 함께 가지는 복합적인 존재
객체는 스스로 판단하고 행동하는 자율적인 존재

객체지향은 객체 단위 안에 데이터와 기능을 한 덩어리로 묶음 으로서, 문제 영역의 아이디어를 함께 표현할 수 있게 했다. 데이터 + 기능을 객체 내부로 함께 묶는 것을 캡슐화라고 한다.
이에 접근 통제가 가능한 점근 제어 메커니즘을 제공한다. 접근 수정자도 제공한다

외부 접근 가능 => public interface, 내부만=> 구현
인터페이스와 구현의 분리 원칙
상태를 숨기고, 행동의 일부를 외부로 보내는 것이 좋다. public만 public interface, 나머지는 구현
프로그래머의 역할은 클래스 작성자와 클라이언트 프로그래머를 구분하는 것이 유용하다
클래스 작성자는 새로운 데이터 타입을 프로그램에 추가한다.
클라이언트 프로그래머는 클래스 작성자가 추가한 데이터 타입을 사용한다
클래스 작성자는, 클라이언트 프로그래머가 알아서 할 수있도록 최소한만 노출하고, 나머지를 숨기는데, 이를 구현 은닉이라고 한다
클라이언트 프로그래머가 마음껏 해도 내부 구현은 계속 바꿀 수 있어야 한다