-
아이템 19 - 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라
2020.12.10
아이템 18에서는 상속을 염두에 두지 않고 설계했고 상속할 때의 위험을 경고했다. 그렇다면 상속을 고려한 설계와 문서화란 정확히 무얼 뜻할까? 우선, 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다. 즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다. 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 그런데 마침 호출되는 메서드가 재정의 가능한 메서드라면 그 사실을 호출하는 메서드의 API 설명에 적시해야 한다. 덧붙여서 어떤 순서로 호출하는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 한다('재정의 가능'이란 public과 protected 메서드 중..
-
아이템 18 - 상속보다는 컴포지션을 사용하라
2020.10.15
상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 잘못 사용하면 오류를 내기 쉬운 소프트웨어를 만들게 된다. 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서라면 상속도 안전한 방법이다. 확장할 목적으로 설계되었고 문서화도 잘 된 클래스도 마찬가지로 안전하다. 하지만 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다. 이전과는 달리 이번 아이템에서 논하는 문제는 (클래스가 인터페이스를 구현하거나 인터페이스가 다른 인터페이스를 확장하는) 인터페이스 상속과는 무관하다. 메서드 호출과는 달리 상속은 캡슐화를 깨뜨린다. 다르게 말하면, 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상..
-
아이템 17 - 변경 가능성을 최소화하라
2020.10.07
변경 가능성을 최소화하라 불변 클래스란... 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있다. String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal이 여기에 속한다. 이 클래스들을 불변으로 설계한 데는 그럴만한 이유가 있다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다. 클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. 클래스를 확장할 수 없도록 한다. 하위 클래스에서 부주의하게 혹은 ..
-
아이템 15 - 클래스와 멤버의 접근 권한을 최소화하라
2020.09.09
잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔하게 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다. 정보 은닉의 장점은 많다. 그중 대부분은 시스템을 구성하는 컴포넌틀들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해주는 것과 연관되어 있다. 정보 은닉의 장점은 아래와 같다. 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. 시스템 관리비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다. 정보 은닉 자체가..
-
아이템72 - 표준 예외를 사용하라
2020.08.23
(그런 사람은 없겠지만, 설레발좀 치겠다) 꾸준히 이 블로그를 눈팅해왔던 사람이라면, 엥? 중간은 어디가고 갑자기 아이템 72인가 하겠다. 이 부분은 내가 피드백 받았던 부분이었는데(상황을 간략히 요약하자면, 무분별한 사용자 정의 예외 사용에 대해서 피드백 받았던 부분이다), 봐도봐도 기억에 남지 않아, 글로 남기고자 한다. 표준 예외를 사용하라 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외를 재사용하면 얻는 게 많다. 당연 그중에 가장 유익한 점은 1) 우리의 API가 다른 사람에게 쉽게 다가온다는 점이다(이미 많은 프로그래머에게 익숙해진 규약을 그대로 따르기 때문이다). 2. 우리의 API도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점도 크다. 3) 마..
-
아이템 12 - toString을 항상 재정의하라
2020.07.30
Object의 기본 toString 메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다. 이 메서드는 PhoneNumber@adbbd처럼 단순히 클래스_이름@16진수로_표시한_해시코드를 반환한다. toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다. 이러한 형식의 값을 읽기 쉽다고 볼 수도 있지만, 707-867-5309처럼 전화번호를 직접 알려주는 형태가 훨씬 유익한 정보를 담고 있다. 또한 toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다. equals와 hashCode 규약(아이템 10, 11)만큼 대단히 중요하진 않지만, toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래..
