한 페이지가 될 수 있게

창발적 설계로 깔끔한 코드를 구현하자 우리는 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 믿고 있습니다. 켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'라고 말합니다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위의 순서는 중요도 순서로 배치되어 있습니다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트할 수 없는 시스템은 검증도 불가능합니다. 논란이 조금 존재하지만, 검증할 수 없는 시스템은 절대 출시해서는 안 됩니다. 테스트 케이스가 많을수록 테스트가 쉽게 코드를 작성할 수 있습니다. 결국 테스트가 가능한 시스템을 만들면 더 나은 설계를 얻을 수 있습니다. 결합도가 높으면 테스트하기 어렵기..

복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. 복잡한 코드를 보게 된다면 읽을 엄두조차 안 나게 되는데 유지보수와 테스트 진행까지 상상해 보았을 때 벌써 생기를 빼앗긴 기분이 듭니다. 이번 장에서는 클래스보다 더 높은 추상화 수준인 시스템 수준에서도 깨끗함을 유지하는 방법에 대해 살펴봅니다. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 객체를 제작하고 의존성은 연결하는 준비 과정과 이후에 이어지는 런타임 로직을 분리해야 합니다. 설정 논리와 일반 실행 논리를 분리해야 모듈성이 높아집니다. Main 분리 간단한 제어 흐름을 가지고 있는 방법입니다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘깁니다. 애플리케이..

객체지향에 갓 입문한 사람들의 가장 흔한 실수는 협력이라는 문맥을 고려하지 않은 채 객체가 가져야 할 상태와 행동부터 고민하기 시작한다는 것이라고 이 책에서 말하고 있습니다. 저 또한 상태와 행동에 해당하는 필드와 메서드부터 고민을 시작하며 객체를 만들고자 했던 것 같습니다. 이런 실수로 인해 진정한 의미를 담은 객체를 온전히 만들어내지 못했던 점을 반성하게 됩니다. 협력 협력의 본질은 요청과 응답으로부터 시작합니다. 하나의 요청은 다른 요청을 발생시키고 그래프처럼 퍼져나가게 됩니다. 결국 네트워크가 구성되고 네트워크 안에서 협력은 필연적으로 존재합니다. 요청 속에는 해당 객체의 의무도 담겨 있습니다. 의무를 다해야 하지만 해당 객체로는 부족하기에 요청이 발생하게 되는 것입니다. 요청과 응답은 협력에 참..

프록시는 무엇을 의미할까요? 이 질문에 앞서 프록시가 등장하게 된 배경에 대해 먼저 알아보도록 하겠습니다. Proxy 등장 배경 객체는 객체 그래프로 연관된 객체들을 자유롭게 탐색할 수 있습니다. 하지만 데이터베이스 매핑을 하는 엔티티 객체에서는 자유도가 떨어집니다. 연관된 테이블의 데이터를 조회하기 위해서는 JOIN을 사용하여 조회를 진행해야 하기 때문입니다. 자유로운 객체 그래프 탐색의 가능성으로 인해 연관된 모든 테이블을 조회하는 것은 비용이 따릅니다. 실제로 연관된 테이블을 사용하지 않는다면 쓸데없이 JOIN을 하여 조회한 결과를 가져오기 때문입니다. 이 문제를 해결하기 위해 프록시가 등장하게 되었습니다. 연관된 객체를 처음부터 데이터베이스에서 조회하는 것이 아니라, 실제 사용하는 시점에 데이터베..

자바는 결국 클래스로 모든 것이 구성되어 있습니다. 코드, 함수에서 더 높은 차원인 클래스까지 신경 써야만 깨끗한 코드를 얻을 수 있습니다. 이 장에서는 깨끗한 클래스에 관한 내용을 다루고 있습니다. 클래스 체계 표준 자바 관례에 따르면 가장 먼저 변수 목록이 나와야 합니다. 정적 공개 상수, 정적 비공개 상수, 비공개 인스턴스 변수 순으로 나열합니다. 공개 변수가 필요한 경우는 거의 존재하지 않습니다. 테스트는 아주 중요한 구성 중 하나이기에 테스트를 위해 protected로 선언하거나 package-private를 사용하기도 합니다. 하지만 이를 사용하기 전 비공개로 할 수 있는가에 대해 끊임없이 고민이 필요합니다. 클래스도 함수와 마찬가지로 작아야만 합니다. 그렇다면 클래스의 크기는 얼마나 작아야 ..