# Effective Java
[Effective java] item 34. int 상수 대신 열거 타입을 사용하라
[Effective java] item 34. int 상수 대신 열거 타입을 사용하라
[Effective java] item 28. 배열보다는 리스트를 사용하라
Effective java - item 28. 배열보다는 리스트를 사용하라 (feat. 왜 미션에서 배열말고 리스트를 사용하라고 하나?)
[Effective java] item 1. 생성자 대신 정적 팩터리 메서드를 고려하라
Effective java - item 1. 생성자 대신 정적 팩터리 메서드를 고려하라
객체 생성과 파괴
객체를 만들어야 하는 경우와 그렇지 않은 경우에 대해 알아보자.클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자다. ( public 방법 말고도 정적 팩터리 메서드를 사용할 수 있다. )1) 첫 번째, 이름을 가질 수 있다. 2) 두 번째,
item37 - ordinal() 인덱싱 대신 EnumMap을 사용하라
생애주기(LifeCycle) 별로 정원내의 화초들을 순회하는 예제를 이 장에서 들고 있다. 클라이언트 내에서 Enum 상수의 종류에 따라 다른 Set을 가진 Map을 가지고 싶을때 EnumMap을 사용하라고 권고하는 챕터이다. HashMap이나 HashSet을 쓸수도
item36 - 비트 필드 대신 EnumSet을 사용하라
예전의 코드들에는 열거하려는 상수 값들이 단독이 아닌 집합으로 사용될 경우 각 상수를 선언할 때마다 2의 거듭제곱을 한번 더 하도록 선언 및 정의하는 경우가 있었다고 한다. 예를 들어 아래와 같은 경우이다. 이와 같은 방식은 구닥다리 기법이라고 설명하고 있다. 위의
item35 - ordinal() 메서드 대신 인스턴스 필드를 사용하라
enum을 처음 사용하는 경우 생성자를 어떻게 사용하는지 잘 모르기 때문에 이것 저것 IDE에서 시도를 하다가 ordinal을 사용하는 경우가 있다. 이 책에서는 그 경우에 대해서 친절하게 어떻게 하면 되는지를 설명하고 있다. 이 책에서는 합주단의 종류를 연주자가 1
Effective Java 31. 한정적 와일드 카드를 사용해 API 유연성을 높이라
Wildcard 매게 변수화 타입은 불공변(invariant)이다. 즉 서로 다른 타입 Type1과 Type2가 있을때 은 의 하위 타입도 상위 타입도 아니다. 즉 은 와 아무 관계도 아니라는 말이다. 이처럼 매개변수화 타입은 고정되어 있지만 때로는 좀 더 유연하
Effective Java 78. 공유 중인 가변 데이터는 동기화해 사용하라
synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장된다.한 객체가 생성되고, 이 객체 접근하는 메서드는 그 객체에 lock을 건다. 락을 건 메서드는 객체의 상태를 확인하고 필요하면 수정한다. 즉, 객체를 하나의 일관된 상태에서 다
Effective Java 77. 예외를 무시하지 말라
예외를 무시하지 말자.안타깝게도 예외를 무시하기란 아주 쉽다. 해당 메서드 호출을 try-catch로 감싼 후 catch 블록에서 아무것도 하지 않으면 된다.예외는 문제 상황에 대처하기 위해 존재하는데, catch블록을 비워두면 예외가 존재할 이유가 사라진다 비유하자면
Effective Java 76. 가능한 한 실패 원자적으로 만들라
작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있다면 멋지지 않을까? 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적 이라고 한다.가장 간단한 방법은 불변 객체로 설계하는 것이다. 불변 객체
Effective Java 75. 예외의 상세 메세지에 실패 관련 정보를 담으라
예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 스택 추적 정보를 자동으로 출력한다. 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다.예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하는 일은 아주 중요하다
Effective Java 74. 메서드가 던지는 모든 예외를 문서화하라
메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보다.검상 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 javadoc의 @throw 태그를 사용하여 정확히 문서화 하자. 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자. ex)
Effective Java 73. 추상화 수준에 맞는 예외를 던지라
수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 이는 윗 레벨 api를 오염 시킬 수 있다. 앞서 서술한 문제를 피하기 위해서는 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꾸어 주어야 한다. 이를 예외 번역이라고 한다
Effective Java 72. 표준 예외를 사용하라
표준 예외를 재사용한다면 얻는것이 많다. 내가 작성한 API가 다른 사람이 익히고 사용하기 쉬워지고, 많은 프로그래머에게 익숙한 규약을 그대로 따르기 때문이다. 그리고 여러분의 코드 역시 읽기 쉬워진다.가장 많이 사용되는 예외이다. 호출자가 인수로 부적절한 값을 넘길
Effective Java 71. 필요 없는 검사 예외 사용은 피하라
검사 예외는 제대로 활용하면 api와 프로그램의 질을 높일 수 있다. 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 물론 검사 예외를 사용하면, 오히려 쓰기 어려운 api가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를
Effective Java 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러, 이렇게 세 가지를 제공하는데, 언제 무엇을 사용해야 하는지 헷갈려 하는 프로그래머들이 있다.호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 이는 검사 예외와 비
Effective Java 69. 예외는 진짜 예외 상황일때만 사용하라
무슨 일을 하는지 절혀 알 수 없는 코드이다. 이 코드는 배열을 순회하는데, 끔찍한 방식으로 진행하고 있다. 무한 루프를 돌다가 배열의 끝에 도달해 예외가 발생하면 끝을 내는 것이다.이 코드는 성능 향상을 위해서 작성했다고 생각할 수 있지만, 표준 관용구(for-loo
Effective Java 68. 일반적으로 통용되는 명명 규칙을 따르라
자바 플랫폼은 명명 규칙이 잘 정립되어 있으며 그중 많은 것이 자바 언어 명세에 기술되어 있다. 명명 규칙은 크게 철저와 문법, 두 범주로 나뉜다.철자 규칙은 패키지, 클래스, 인터페이스 등 변수의 이름을 다룬다. 이 규칙은 특별한 이유가 없는 한 반드시 따라야 한다.