Effective Java

클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자다. 클래스는 생성자와 별도로 정적 팩터리 메서드를 제공 할 수 있다.다음 코드는 boolean 기본 타입의 박싱 클래스인 Boolean에서 발췌한 간단한 예다지금 얘기하는 정적 팩터리 메서드는 디

정적 팩터리와 생성자에는 똑같은 제약이 하나있다. 선택적 매개변수가 많을때 적절히 대응하기 어렵다는 점이다.프로그래머들은 보통 점층적 생성자 패턴을 즐겨 사용했다.이 클래스의 인스턴스를 만드려면 원하는 매개변수를 모두 포함한 생성자중 가장 짧은것을 호출하면된다.보통 이

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다. 이런 자원 중 상당수가 안정망으로 finalizer를 활용하고는 있지만 finalizer는 그리 믿을만

equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있어서 자칫하면 끔직한 결과를 초래한다.문제를 회피하는 가장 쉬운길은 아예 재정의 하지 않는 것이다. 그러므로 밑의 상황중 하나에 해당하면 재정의 하지 않는것이 최선이다.각 인스턴스가 본질적으로 고유

equals를 재정의한 클래스 모두에서 hashcode도 재정의해야 한다. 그렇지 않으면 hashcode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet같은 컬렉션의 원소로 사용할때 문제를 일으킨다.equals 비교에 사용되는 정보가

Cloneable은 복제해도 되는 클래스임을 명시하는 용도인 믹스인 인터페이스지만, 아쉽게도 의도한 목적을 제대로 이루지 못했다. 가장 큰 문제는 clone 메서드가 선언된 곳이 Clonealbe이 아닌 Obejct이고, 그마저도 protected라는데 있다. 하지만

이번에는 Comparable 인터페이스의 유일무이한 메서드인 ComapreTo를 알아보자. 이번 장에서 다룬 다른 메서들과 다른 compareTo는 Object의 메서드가 아니다.Comparable을 구현 했다는 것은 그 클래스의 인스턴스들에 자연적인 순서가 있음을 뜻

[아이템 17]. 변경 가능성을 최소화하라

[아이템 20]. 추상 클래스보다는 인터페이스를 우선하라.

[아이템 22]. 인터페이스는 타입을 정의하는 용도로만 사용하라.

[아이템 23]. 태그 달린 클래스보다는 클래스 계층 구조를 이용하라.

[아이템 24]. 멤버 클래스는 되도록 static으로 만들라

[아이템 25]. 톱레벨 클래스는 한 파일에 하나만 담으라.

[아이템 26]. 로 타입은 사용하지 말라.

[아이템 28]. 배열보다는 리스트를 사용하라.

[아이템 29]. 이왕이면 제네릭 타입으로 만들라.

[아이템 30]. 이왕이면 제네릭 메서드로 만들라

[아이템 31]. 한정적인 와일드 카드를 이용해 API 유연성을 높여라

매개변수화 되는 대상은 원소가 아닌 컨테이너 자신이다. Set가 있을 때 매개변수화 되는 것은 Integer가 아니라 List이다.하나의 컨테이너에서 매개변수화 할 수 있는 타입의 수가 제한된다. 이보다 유연한 수단 : 타입 안전 이종 컨테이너 패턴타입 안전 이종 컨

### [아이템 34]. int 상수 대신 열거타입을 사용하라

[아이템 35]. ordinal 메서드 대신 인스턴스 필드를 사용하라

아이템38 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라

[아이템 36]. 비트 필드 대신 EnumSet을 사용하라

명명 패턴보다 애너테이션을 사용하라

[아이템40]. @Override 애너테이션을 일관되게 사용하라

[아이템41]. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라