본문 바로가기

java/이펙티브 자바

(14)
Item29~30 Item23~24 진성 Item25~26 제이크 Item27~28 가을 Item29~30 워니민이 Item31~32 인호 Item33~34 민이워니 ITEM 29. 이왕이면 제네릭 타입으로 만들어라 일반클래스 -> 제네릭 클래스 클라이언트에서 직접 형변환해야하는 타입보다 제네릭 탁입이 더 안전하고 쓰기 편한다. 그러니 새로운 타입을 설계할 때는 형변환 없이도 사용할 수 있도록 해라. 그렇게 하려면 제네릭 타입으로 만들어야 할 경우가 많다. 기존 타입 중 제네릭이었어야 하는게 있다면 제네릭 타입으로 변경하자. 기존 클라이언트에는 아무 영향을 주지 않으면서, 새로운 사용자를 훨씬 편하게 해주는 길이다. 0. 왜 제네릭을 사용하는가? 자바5부터 제네릭 타입이 추가되었다. 제네릭 타입을 사용함으로 잘못된 타입이..
[item 21~22] Item9~Item10 AJ Item11~Item12 가을 Item13~Item14 AJ Item15~Item16 김인호 Item17~Item18 민이/워니 Item19~Item20 Jake Item21~Item22 워니/민이 item 21 인터페이스는 구현하는 쪽을 생각해 설계하라 자바 8 이전에는 기존 구현체를 깨뜨리지 않고 인터페이스에 메서드를 추가하는 방법이 없었다 인터페이스에 메서드를 추가하면 보통은 컴파일 오류가 나는데 추가된 메서드가 우연히 기존 구현체에 이미 존재할 가능성이 낮기 때문이다. 생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어려운 법이다 자바 8 Collection 인터페이스에 추가된 디폴트 메서드 default boolean removeIf(P..
[item 1] 생성자 대신 정적 팩터리 메서드를 고려하라 [item 1] 생성자 대신 정적 팩터리 메서드를 고려하라 정적 팩터리 메서드는 디자인 패턴에 없다. 생성자 VS 정적 팩터리 메서드 ....... 장점 이름을 가질 수 있다 probablePrime 생성자는 이름이 없다. 매개변수 갯수로 오버로딩되어 구분할 뿐... public class BigInteger { BigInteger(int, int, Random){ ..... } // 생성자 } 정적 팩터리 메서드는 이름만 잘 지으면 반환 될 객체의 특성을 쉽게 묘사할 수 있다. public class BigInteger { BigInteger(int, int, Random){ ..... } // 생성자 void probablePrime( ){.......} // 메서드 선언 } 호출 될 때 마다 인스턴..
[item 17~18] Item9~Item10 AJ Item11~Item12 가을 Item13~Item14 AJ Item15~Item16 김인호 Item17~Item18 민이/워니 Item19~Item20 Jake Item21~Item22 워니/민이 4장 클래스와 인터페이스 item 17 변경 가능성을 최소화하라 클래스는 불변 클래스로 사용해라 불변 클래스가 아니라면 변경 부분을 최소한으로 줄이자 모든 필드는 private final 불변 클래스는 장점이 많다. 단점이라고는 잠재적 성능 저하 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬어지고, 오류 가능성이 낮아진다. 변경해야할 필드를 제외하고 final로 선언하자 모든 필드는 private final이어야 한다 생성자는 불변식 설정이 완료된 초기화가 끝난 ..
[item 8] finalizer와 cleaner 사용을 피하라 [item 8] finalizer와 cleaner 사용을 피하라 자바 객체 소멸자, finalizer와 cleaner 자바에서는 두 가지 객체 소멸자를 제공한다. 바로 finalizer와 cleaner가 있다. finalizer cleaner finalizer는 예측할 수 없으며, 상황에 따라 위험하므로 일반적으로 불필요하다. 자바 9부터는 finalizer를 deprecated API로 지정하고 대안으로 cleaner를 소개한다. cleaner는 별도의 스레드에서 동작해서 finalizer보다 덜 위험하다고 생각할 수 있다. 하지만, cleaner도 여전히 예측할 수 없으며, 느리고, 일반적으로 불필요하다. 수행시점 수행 여부 조차 보장하지 않는다. 성능도 느림 수행시점 수행 여부 조차 보장하지 않는다..
[item 7] 다 쓴 객체 참조를 해제하라 OutOfMemoryError 본 적 있죠? C, C++ 언어는 명시적으로 메모리를 할당해서 사용하고 자원을 다 사용하고 나면 개발자가 명시적으로 해제를 한다. 가비지 컬렉터를 갖춘 자바와 같은 언어를 사용하면, 가비지 컬렉터가 다 쓴 객체를 알아서 회수한다. 그래서 메모리 문제를 개발자가 전혀 신경쓰지 않아도 된다고 오해할 수 있다. 메모리 누수 현상이 발생하니 null을 입력하라. package com; import java.util.Arrays; import java.util.EmptyStackException; public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_IN..