Effective Java study

이팩티브 자바를 시작한지 4주가 지났다. 이제와서 올리게 되었다... 매주 스터디 이전에 발표도 꺼리게되고, 책도 펴기 힘들다. 하지만 잠깐의 귀찮음을 이겨내고 스터디에 참가해 다른 사람들의 발표를 들으며 부족했던 부분을 많이 배우고, 발표를 진행하며 애매했던 부분도

자바는 두 가지 객체 소멸자를 제공finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있다기본적으로 쓰지말아야 한다. 자바9 부터는 deprecated대안으로 cleaner가 생겼지만 이것도 쓰면 안됨이 책에서는 try-with-resource와 try-fin

클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는가.오직 API를 통해서만 다른 컴포넌트와 소통하며, 서로의 내부 동작 방식에는 전혀 개의치 않는다.정보 은닉, 캡슐화 라고 한다.시스템 개발 속도를 높인다. \- 여러 컴포넌트를 병렬로 개발할

인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할만 하는데, 오직 이 용도로만 사용해야 한다.상수 인터페이스라는 안티패턴이 있는데, 절대 사용하지말라고 한다.상수 인터페이스 안티패턴은 인터페이스를 잘못 사용한 예이다.클래스 내부에서 사용하는 상수

List 은 List의 하위타입이 아니다. List 는 List 가 하는 일을 제대로 수행하지 못하니 리스코프 치환 원칙에 어긋난다. Stack.java Main.java 위의 코드와 같이 Stack로 클래스를 선언한 뒤, Number의 하위타입인 Integer

자바가 기본으로 제공하는 애너테이션 중에서 보통 가장 중요한 어노테이션으로 @Override 을 꼽을 수 있다.이 어노테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해준다.Object의 equals를 override를 하려면 매개변수가 Object여야 하

자바 7까지는 일련의 원소를 반환하는 메서드에서 번환 타입으로 Collection, Set, List와 같은 컬렉션 인터페이스(기본) 혹은 Iterable이나 배열을 사용했다.예외1 - for-each 문에서만 쓰이거나 반환된 원소 시퀀스가 일부 Collection 메

잘 활용하면 배우기 쉽고, 쓰기 쉬우며, 오류 가능성이 적은 API를 작성 가능하다!같은 패키지에 속한 다른 이름들과 일관되게 짓는게 최우선개발자 커뮤니티에서 널리 받아들여지는 이름 사용긴 이름은 피하자 자바 라이브러리가 워낙 방대하다 보니 일관되지 않은 이름도

가변인수(varagas) 메서드는 명시한 타입의 인수를 0개 이상 받을 수 있다. 인수의 개수와 길이가 같은 배열을 만든다.인수들을 이 배열에 저장하여 가변인수 메서드에 건네준다.인수의 갯수는 런타임에 배열의 길이로 알 수 있다.위 코드는 문제가 있는 코드이다.가장 심

하지만 원래 의도하지 않은 용도로 쓰이는 경향이 있고, 이번 아이템에서는 문자열을 쓰지 않아야 할 사례를 다룬다.많은 사람들이 데이터를 받을 때 주로 문자열을 사용한다. (우리회사가 그럼... DTO가 전부 String...)하지만 문자열은 다른 값 타입을 대신하기에

[Item64] 객체는 인터페이스를 사용해 참조하라 아이템 51의 매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라와 비슷한 내용이다. 위의 내용을 확장하여 객체는 클래스가 아닌 인터페이스로 참조하라는 말이다. 적합한 인터페이스만 있다면 매개변수뿐 아니라 반

예외를 완전히 잘못 사용한 예.전혀 직관적이지 않다는 사실만으로도 코드를 이렇게 작성하면 안된다!무한루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException를 던지며 끝을 낸다.같은 동작을 유도한 코드이지만 직관적으로 코드가 하는 일을

수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다.이는 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다.구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언