1. raw 타입은 사용하지 말라 raw 타입이란 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을 때를 말한다 예컨대 List의 raw 타입은 매개변수가 없는 제네릭 타입인 List다 raw 타입은 타입 선언에서 제네릭 타입 정보가 전부 지워진 것처럼 동작하는데, 제네릭이 도래하기 전 코드와 호환되도록 하기 위한 궁여지책이라 할 수 있다 제네릭을 지원하기 전에는 컬렉션을 다음과 같이 선언했다 // Stamp 인스턴스만 취급한다 private final Collection stamps = ...; // 실수로 동전을 넣는다 stamps.add(new Coin(...));// "unchecked call" 경고 이 코드를 사용하면 실수로 도장(Stamp) 대신 동전(Coin)을 넣어도 아무 오류 없이 컴..

5. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 상속을 염두에 두지 않고 설계했거나, 상속할 때의 주의점을 문서화해놓지 않은 '외부' 클래스를 상속할 때 위험을 경고한다 여기서 '외부'란 프로그래머의 통제권 밖에 있어서 언제 어떻게 변경될지 모른다는 뜻이다 5.1 그렇다면 상속을 고려한 설계와 문서화란 정확히 무얼 뜻할까? 우선 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다 즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기사용) 문서로 남겨야 한다 재정의할 수 있는 메서드(public과 protected 메서드 중 final이 아닌 모든 메서드)는 API 설명을 적시해야 한다 어떤 순서로 호출하는지, 각각의 호출 ..

추상화의 기본 단위인 클래스와 인터페이스는 자바 언어의 심장과도 같다. 자바 언어에는 클래스와 인터페이스 설계에 사용하는 강력한 요소가 많이 있다. 이번 장에서는 이런 요소를 적절히 활용하여 클래스와 인터페이스를 쓰기 편하고, 견고하며, 유연하게 만드는 방법을 안내한다. 1. 클래스와 멤버의 접근 권한을 최소화하라 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다 1.1 캡슐화의 장점은 다음과 같다 시스템 개발 속도를 높인다 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다 시스템 관리 비용을 낮춘다 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 ..

Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로는 상속해서 사용하도록 설계되었다 Object에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의(overriding)를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다 이번 장에서는 언제 어떻게 재정의해야 하는지 다룬다 1. equals는 일반 규약을 지켜 재정의하라 1.1 equals를 재정의할 필요가 없는 경우 equals 재정의 시 문제가 발생하는 일을 회피하는 가장 쉬운 길은 아예 재정의 하지 않는 것이다 다음 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다 각 인스턴스가 본질적으로 고유하다 값을 표현하는 게 아니라 동작..

객체를 만들어야 할 때와 만들지 말아야 할 때를 구분하는 방법 올바른 객체 생성 방법과 불필요한 생성을 피하는 방법 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 방법 1. 생성자 대신 정적 팩토리 메서드를 고려하라 정적 팩토리 메서드는 디자인 패턴에서의 팩토리 메서드를 의미하는 게 아님! 1.1 팩토리 메서드의 장점 5가지 1) 이름을 가질 수 있다 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다 반면 정적 팩토리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다 예를 들어 생성자 BigInteger(int, int, Random) vs 정적 팩토리 메서드 BigInteger.probabalPrime 어느 쪽이 값이 소수인 B..

안티패턴을 피하라! 아주 핵심적인 기본 원칙 명료성과 단순성 컴포넌트는 사용자를 놀라게 하는 동작을 해서는 절대 안된다 (정해진 동작이나 예측할 수 있는 동작만 수행해야 한다) 컴포넌트는 가능한 한 작되, 그렇다고 너무 작아서는 안된다 코드는 복사되는 게 아니라 재사용되어야 한다 컴포넌트 사이의 의존성은 최소로 유지해야 한다 오류는 만들어지자마자 가능한 한 빨리 잡아야 한다 이 규칙들이 100% 옳을 수는 없겠지만, 거의 모든 경우에 적용되는 최고의 모범 사례일 것이다 이 규칙들을 생각 없이 맹종하진 말아야 하나, 어겨야 할 때는 합당한 이유가 있어야 한다 마무리 느낀점 아직 상세 내용을 보지 않아서 두리뭉실한 내용들이 있지만 여기서 이야기 하고자하는 규칙들 역시 클린코드 내용과 일맥상통하는 부분이 많아..