한 페이지가 될 수 있게

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

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

애플리케이션 실행에는 무수히 많은 변수가 존재합니다. 이러한 변수 상황을 효율적으로 대처하기 위해 테스트의 중요성은 시간이 지날수록 꾸준히 증가하였고 지금은 TDD라는 용어까지 나오며 테스트가 필수적으로 되었습니다. 형식 맞추기로 테스트를 급하게 작성해서는 안 되고 제대로 된 테스트 케이스를 작성할 수 있도록 테스트에 많은 시간을 투자해야 합니다. TDD 법칙 세 가지 첫째. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 둘째. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 셋째. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 지저분한 테스트 코드는 개발 비용을 증가시킵니다. 핵심 로직에 투자해야 할 시간을 ..

프로젝트의 하나로 앱 개발을 진행할 때 앱에 필요한 모든 소프트웨어를 직접 개발하지는 않았습니다. 규격화 되어 있는 오픈 소스를 이용하고 다른 팀의 API를 사용하고 필요에 의해 비용을 지불하고 라이선스를 획득하여 사용하기도 합니다. 외부의 코드를 사용하게 되면 내부의 코드와 적절히 조화를 이루도록 하는 것이 중요한 부분인데 이번 장에서는 이러한 경계를 깔끔하게 처리하는 기법과 기교를 설명하고 있습니다. 외부 코드 사용하기 코드 제공자는 적용성과 범용성을 넓히기 위해 최대한 노력합니다. 하지만 이러한 적용성과 범용성이 단점으로 다가오는 상황도 존재합니다. 너무 많은 기능을 제공해버리면 클라이언트에서 필요하지 않은 기능까지 제공해버리게 됩니다. 이를 적절히 캡슐화하여 기능을 제한하면 클라이언트로서 편할 것..

무엇이 잘못된다면 이를 바로 잡을 책임은 프로그래머에게 달려 있습니다. 그렇기에 깨끗한 코드와 오류 처리는 밀접한 관련이 있습니다. 하지만 오류 처리로 인해 중요한 로직이 가려지게 된다면 이는 제대로 된 오류 처리라 부를 수 없습니다. 이번 장을 통해 우아하고 고급스럽게 오류 처리하는 방법과 고려 사항에 대해 정리해보고자 합니다. 오류 처리를 생각했을 때 바로 떠오르는 방법들도 있습니다. 오류 코드보다 예외를 사용하라 Try-Catch-Finally 문부터 작성하라 예외에 의미를 제공하라 미확인 예외를 사용하라 확인된 예외는 컴파일 단계에서 확인되며 반드시 처리되어야 하는 예외입니다. 미확인 예외는 런타임 시 확인되며 명시적인 처리를 강제하지 않는 예외입니다. 확인된 예외는 안정적인 소프트웨어를 위해 사..