이펙티브자바

이름을 가질 수 있다.하나의 시그니처로 다른 이름을 갖는 메소드를 생성할 수 있음호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.인스턴스 통제 → 싱글턴 가능, 인스턴스화 불가로 만들 수 있음메모리 효율반환타입의 하위타입 객체(Child)를 반환 할 수 있다.자바

논리적 동치성을 검사할 필요가 있는 경우엔 equals메서드를 규약에 따라 재정의하자꼭 필요한 경우가 아니라면 재정의 X구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 수 없다.상속 대신 컴포지션을 사용하자equals의 판단에 신뢰할 수 없는

모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시키는 편이 낫다.클래스의 공개 API외의 모든 멤버는 private로

로타입은 뭐든지 다 들어간다. → 꺼낼 때, 값을 항상 올바른 타입으로 캐스팅해줘야 한다. → 타입안정성, 표현력을 잃게 된다.비한정적 와일드카드 타입(ex. List<?>)은 어떤 타입이든 상관없이 받을 수 있어 타입안정성을 보장해준다.얘는 null외에 아무것도

아이템 34. int 상수 대신 열거 타입을 사용하라 아이템 35. ordinal 메서드 대신 인스턴스 필드를 사용하라

람다는 이름 없고, 문서화 불가능. 명확하지 않고, 라인이 많으면 람다 사용 X람다가 대체할 수 없어 익명클래스를 사용해야 하는 곳 1\. 람다는 함수형 인터페이스에서만 쓰임추상 클래스의 인스턴스를 만들 때 람다를 쓸 수 없음추상 메서드가 여러 개인 인터페이스의 인스턴

메서드 몸체 실행 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적으로 예외를 던질 수 있다. Fail fast!public, protected 메서드는 매개변수 값이 잘못됐을 때의 예외를 문서화해야 한다 (@throws 태그 활용)클래스 수준 주석은 모든 p

지역변수 유효범위를 최소로 줄이면 가독성, 유지보수성 높아지고, 오류가능성은 낮아진다지역변수는 가장 처음 쓰일 때 선언하자, 선언과 동시에 초기화하자try-catch는 예외 : 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 있다면 try블록 안에서 초기화, 변

예외를 제어 흐름용으로 사용하지 말자 예외를 제어 흐름에 사용하는 것은 표준 관용구보다 훨씬 느리다예외를 제어 흐름에 사용하면, 흐름 제어에 사용한 예외가 버그를 숨겨 디버깅이 어려워진다예외는 오직 예외 처리 용도로만 사용하자호출하는 쪽에서 복구하리라 생각되는 경우엔

동기화는 배타적 실행뿐 아니라 스레드 사이의 안정적인 통신에 꼭 필요하다.안정적인 통신에는 volatile을 사용하면 된다. (배타적 실행은 보장 x)예: ++ 연산자 (하나의 연산으로 보이지만 사실은 조회, 증가 후 저장)두 번째 스레드가 첫 번째 스레드의 연산 사이

직렬화는 공격 범위가 넓어 방어하기 어렵다.ObjectInputStream의 readObject 메서드를 호출하면서 객체 그래프가 역직렬화된다. 이는 클래스패스 안의 모든 타입의 객체를 만들어 낼 수 있다. → 코드 전체가 공격 범위직렬화 위험을 피하는 방법은 아무것도