개발자는 기록이 답이다

4. 자율적인 객체를 향해 캡슐화를 지켜라 캡슐화는 설계의 제 1원리이다. 데이터 중심의 설계가 낮은 응집도와 높은 결합도라는 문제를 가진 것은 캡슐화의 원칙을 위반했기 때문이다. 객체는 자신이 어떤 데이터를 가지고 있는지를 내부에 캡슐화하고 외부에 공개하면 안된다. 스스로의 상태를 책임져야 하며 외부에서는 인터페이스에 정의된 메서드를 통해서만 상태에 접근할 수 있어야 한다. 여기서 메서드란 단순히 속성 하나의 값을 반환하거나 변경하는 접근자나 수정자를 의미하는게 아니다! 객체가 책임져야 하는 무언가를 수행하는 메서드다! 속성의 가시성을 private으로 설정했다고 해도 접근자와 수정자를 통해 속성을 외부로 제공하고 있다면 캡슐화를 위반하는 것이다. 사각형을 표현하는 간단한 클래스를 살펴보자. 아래 클래..

3. 구현을 통한 검증 Screening을 구현하는 것으로 시작하자. Screening은 영화를 예매할 책임을 맡으며 그결과로 Reservation 인스턴스를 생성할 책임을 수행해야 한다. 다시 말해 Screening은 예매에 대한 정보 전문가인 동시에 Reservation의 창조자이다. 협력의 관점에서 예매하라 메시지에 응답할 수 있어야 한다. package chapter5.movie; public class Screening { public Reservation reserve(Customer customer, int audiencCount) {} } 책임이 결정됐으므로 책임을 수행하는데 필요한 인스턴스 변수를 결정해야 한다. 상영 시간, 상연 순번, Movie에 가격을 계산하라 메시지를 전송해야 하기..

4장에서는 데이터 중시의 접근법을 취할 경우 직면하는 다양한 문제점을 살펴봤다. 데이터 중심의 설계는 행동보다 데이터를 먼저 결정하고 협력이라는 문맥을 벗어나 고립된 객체의 상태에 초점을 맞추기 대문에 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며,코드를 변경하기 어려워진다. 따라서 책임에 초점을 맞춰야 한다. 책임에 초점을 맞춰서 설계할 때 직면하는 가장 큰 어려움은 어떤 객체에 어떤 책임을 할당하는지 결정하기 쉽지 않다는 것이다. 책임 할당 과정은 일종의 트레이드 오프 활동이다. 동일한 문제를 해결할 수 있는 다양한 책임 할당 방법이 존재하며, 어떤 방법이 최선인지는 상황과 문맥에 따라 달라진다. 따라서 올바른 책임을 할당하기 위해서는 다양한 관점에서 설계를 평가할 수 있어야 한다. GRS..

1. 동기화 메소드와 동기화 블록 공유 객체를 사용할 때의 주의할 점 싱글 스레드 프로그램에서는 한 개의 스레드가 객체를 독차지해서 사용하면 되지만, 멀티 스레드 프로그램에서는 스레드들이 객체를 공유해서 작업해야 하는 경우가 있다. 이 경우, 스레드 A를 사용하던 객체가 스레드 B에 의해 상태가 변경될 수 있기 때문에 스레드 A가 의도했던 것과는 다른 결과를 산출할 수도 있다. 이는 마치 여러 사람이 계산기를 함께 나눠 쓰는 상황과 같아서 사람 A가 계산기로 작업을 하다가 계산 결과를 메모리에 저장한 뒤 잠시 자리를 비웠을 때 사람 B가 계산기를 만져서 앞 사람이 메모리에 저장한 값을 다른 값으로 변경하는 것과 같다. 그런 다음 사람 A가 돌아와 계산기에 저장된 값을 이용해서 작업을 진행한다면 결국 사람..