개발자는 기록이 답이다

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

한샘 2차 면접 준비를 앞두고, 레거시를 마이그레이션할때 어떻게 해야하는지 궁금했고 재직자분께 해당 섹션을 추천받아서 보게 되었다. (혹시 이미지와 관련하여 문제가 되는 부분이 있다면 삭제하겠습니다.) 📣 발표자 : 우아한형제들 권용근님 1. 레거시 개편은 왜 일어나는가? 레거시 시스템이란? 간단하게 말해서 낡은 시스템을 말한다. 현재는 비주류인 기술 많은 사람들이 좋아하고 선호했던 기술이 시간이 지나면서 잊혀지거나 시대를 역행하는 아키텍처라고 판단되서 비주류가 되는 기술 현재는 성능이 부족한 시스템 과거에는 요청을 다 처리했지만, 트래픽도 늘어나고 새로운 요구사항을 하면서 성능적인 챌린지도 하다보니 성능적으로 부족한 시스템 새로운 요구사항을 대응할 수 없는(어려운) 시스템 과거의 요구사항은 주어진대로 ..

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

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