Effective Java
1.[Effective Java] Item2. 생성자에 매개변수가 많다면 빌더를 고려하라
Item1에서 클래스에서 인스턴스를 생성하는 생성자와 static 팩토리 메서드를 배웠다.그러나 두 방법에는 똑같은 문제가 하나 있다."선택적 매개변수가 많을 때 적절히 대응하기 어렵다."라는 것이다.이제 선택 매개변수가 많은 상황에서 대처법을 배워본다.필수 매개변수
2.[Effective Java] Item1. 생성자 대신 팩토리 메서드를 고려하라
이 책의 대부분의 내용은 2가지 원칙에서 파생된다.(명료성, 단순성)정해진 동작이나 예측할 수 있는 동작만 수행해야 한다.컴포넌트는 가능한한 작되, 그렇다고 너무 작아서는 안된다.코드는 복사되는게 아니라 재사용되어야 한다.컴포넌트 사이의 의존성은 최소로 유지해야 한다.
3.[Effective Java] Item3. private 생성자나 열거 타입으로 싱글턴임을 보증하라
한정된 값만 갖는 데이터 타입열거된 상수는 각 하나의 Week 객체다.인스턴스를 오직 하나만 생성할 수 있는 클래스이제 싱글턴을 만드는 방식을 알아본다.생성자를 private으로 감춘다.public static final 필드를 이용해, 객체를 딱 한번만 생성한다.코드
4.[Effective Java] Item4. 인스턴스화를 막으려거든 private 생성자를 사용하라.
단순히 static 메서드와 static 필드만 담은 클래스를 만들고 싶을 때가 있다.java.lang.Math 나 java.utils.Arrays 처럼, 기본 타입 값이나 배열 관련 메서드들을 모아놓을때java.utils.Collections 처럼 특정 인터페이스의
5.[Effective Java] Item6. 불필요한 객체 생성을 피하라
똑같은 기능의 객체를 매번 생성하기보단 객체 하나를 재사용하는 편이 낫다.그런데 이때 객체 생성이 너무 빈번하고 불필요하게 이루어지면 문제가 될 수 있다.위 코드는 하지 말아야 할 극단적인 예다.실행될 때마다 String 인스턴스를 새로 만든다.생성자에 넘겨진 "bik
6.[Effective Java]Item7. 다 쓴 객체 참조를 해제하라
c,c++처럼 메모리를 직접 관리하는 언어를 사용하다 java를 사용하면 가비지컬렉터로인해 직접 메모리를 해제하지 않아도된다.하지만 이는 메모리 관리에 더 이상 신경쓰지 않아도 된다는 말이 아니다.메모리 누수를 일으키는 주범들이 있다.메모리 누수가 일어나는 위치는?St
7.[Effective Java]Item8. finalizer와 cleaner 사용을 피하라
java는 2가지 객체 소멸자를 제공한다.그중 finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다.오동작, 낮은 성능, 이식성 문제의 원인이 되기도 한다.finalizer는 나름의 쓰임새가 몇 가지 있긴 하지만 기본적으로 쓰지 말아야
8.[Effective Java]Item9. try-finally보다는 try-with-resources를 사용하라
java lib에는 close메서드를 호출해 직접 닫아줘야 하는 자원이 많다.예로 InputStream,OutputStream,java.sql.Connection 등등이 있다.자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다.이런 자원
9.[Effective Java] Item5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
많은 클래스가 하나 이상의 자원에 의존한다.예를들어 맞춤법 검사기는 사전에 의존하는데, 이런 클래스를 static 유틸리티 클래스로 구현한 모습을 종종 볼 수 있다.실제로 언어별로도 사전이 다양하며 test 등등 다양한 사전이 존재한다.그러나 위 예제들은 위 예제들은
10.[Effective Java]Item18. 상속보다는 컴포지션을 사용하라
상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다.잘못 사용하면 오류를 내기 쉬운 s/w를 만들게 된다.상위,하위 클래스 모두 같은 개발자가 통제하는 패키지 안에서라면 상속도 안전한 방법이다.확장할 목적으로 설계되었고 문서화도 잘 된 클래스도 안전하다.하
11.[Effective Java]Item19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라
상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야한다.재정의 가능한 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야한다.상속이 캡슐화를 해치기 때문이다.안전하게 상속할 수 있도록 하려면 내부 구현 방식을 설명해야만 한다.방법은
12.[Effective Java]Item28. 배열보다는 리스트를 사용하라
배열은 공변인다.sub\[]가 super\[]의 하위 타입이라면 함께 변한다.반대로 제네릭은 불공변이다. 즉, List<"type1">,List<"type2">는 상위도 아니고 하위도 아니다.이것만 보면 제네릭에 문제가 있다고 생각할 수도 있지만, 사실 문제
13.[Effective Java]Item29. 이왕이면 제네릭 타입으로 만들라
jdk가 제공하는 제네릭 타입과 메서드를 사용하는 일은 일반적으로 쉬운편이지만, 제네릭 타입을 새로 만드는 일은 조금 더 어렵다.위 클래스는 제네릭 타입이어야 마땅하다.스택에서 꺼낸 객체를 형변환해야하는데(ex. ensureCapacity) 런타임 오류가 날 위험이 있
14.[Effective Java]item36. 비트 필드 대신 EnumSet을 사용하라
비트별 OR를 사용해 여러 상수를 하나의 집합으로 모을 수 있는 집합여러 컬러가 있고 text에 여러 style을 적용정수 열거 상수의 단점을 그대로 지님(ex. 1이 "굵게"를 의미하는지, "기울임"을 의미하는지 코드만 보고는 알기 어려움)비트 필드 값이 그대로 출력
15.[Effective Java] 37. ordinal 인덱싱 대신 EnumMap을 사용하라
배열에서 인덱스를 얻고자 한다면 ordinal을 종종 사용할 수 있다.그런데 ordinal 인덱싱은 좋지않다.ordinal을 통한 배열 인덱싱은 사실상 내부적으로 많은 문제를 야기한다.해당 타입의 정수 값이 정말 올바른지를 판단할 수 없어서 런타임에서나 되어야 에러를
16.[Effective Java] 45. 스트림은 주의해서 사용하라
스트림 api는 다량의 데이터 처리 작업을 돕고자 java8에 추가되었다.이 api가 제공하는 추상 개념 중 핵심은 2가지다.스트림은 데이터 원소의 유한 혹은 무한 시퀀스를 뜻한다.스트림 파이프라인은 이 원소들로 수행하는 연산 단계를 표현하는 개념이다. (1번의 원소)
17.[Effective Java] 46. 스트림에서는 부작용 없는 함수를 사용하라
스트림은 처음 봐서는 이해하기 어렵고, 장점이 무엇인지 쉽게 와 닿지 않을 수 있다.스트림은 또 하나의 api가 아닌, 함수형 프로그래밍에 기초한 패러다임이기 때문이다.스트림 패러다임의 핵심은 계산을 일련의 변환으로 재구성하는 부분이다.이때 각 변환 단계는 가능한 한