# Effective Java

gosgjung

생애주기(LifeCycle) 별로 정원내의 화초들을 순회하는 예제를 이 장에서 들고 있다. 클라이언트 내에서 Enum 상수의 종류에 따라 다른 Set을 가진 Map을 가지고 싶을때 EnumMap을 사용하라고 권고하는 챕터이다. HashMap이나 HashSet을 쓸수도

gosgjung

예전의 코드들에는 열거하려는 상수 값들이 단독이 아닌 집합으로 사용될 경우 각 상수를 선언할 때마다 2의 거듭제곱을 한번 더 하도록 선언 및 정의하는 경우가 있었다고 한다. 예를 들어 아래와 같은 경우이다. 이와 같은 방식은 구닥다리 기법이라고 설명하고 있다. 위의

gosgjung

enum을 처음 사용하는 경우 생성자를 어떻게 사용하는지 잘 모르기 때문에 이것 저것 IDE에서 시도를 하다가 ordinal을 사용하는 경우가 있다. 이 책에서는 그 경우에 대해서 친절하게 어떻게 하면 되는지를 설명하고 있다. 이 책에서는 합주단의 종류를 연주자가 1

ljinsk3

Java 라이브러리는 대표적으로 String, BigInteger, BigDecimal 같은 불변 클래스를 제공한다.가변 클래스보다 설계, 구현, 사용이 쉽다.오류가 생길 여지도 적고, 훨씬 안전하다.객체의 상태를 변경하는 메서드(변경자, setter)를 제공하지 않는

ljinsk3

위 public 클래스처럼 단순히 데이터만 모아 놓은 클래스가 존재한다고 가정해보자.현재 필드가 모두 public열려 있기 때문에 외부에서 누구든지 언제든지 접근해서 데이터를 변경할 수 있다.이는 객체지향의 핵심원리인 캡슐화를 위반하게 된다.또한 API를 변경하지 않고

ljinsk3

시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발 가능시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅 가능. 다른 컴포넌트로 교체하는 부담도적음성능 최적화에 도움을 준다.소프트웨어 재사용성을 높인다. 외부에 의존하지 않고 독자적으로 동작할 수

ljinsk3

Comparable 인터페이스를 구현하면, compareTo 메서드를 구현해야한다.compareTo는 Object의 메서드가 아니며, equals와 두가지가 다르다.compareTo는 단순 동치성 비교에 더해 순서까지 비교할 수 있으며, 제너릭하다.compareTo를

eversong

Wildcard 매게 변수화 타입은 불공변(invariant)이다. 즉 서로 다른 타입 Type1과 Type2가 있을때 은 의 하위 타입도 상위 타입도 아니다. 즉 은 와 아무 관계도 아니라는 말이다. 이처럼 매개변수화 타입은 고정되어 있지만 때로는 좀 더 유연하

eversong

synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장된다.한 객체가 생성되고, 이 객체 접근하는 메서드는 그 객체에 lock을 건다. 락을 건 메서드는 객체의 상태를 확인하고 필요하면 수정한다. 즉, 객체를 하나의 일관된 상태에서 다

eversong

예외를 무시하지 말자.안타깝게도 예외를 무시하기란 아주 쉽다. 해당 메서드 호출을 try-catch로 감싼 후 catch 블록에서 아무것도 하지 않으면 된다.예외는 문제 상황에 대처하기 위해 존재하는데, catch블록을 비워두면 예외가 존재할 이유가 사라진다 비유하자면

eversong

작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있다면 멋지지 않을까? 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적 이라고 한다.가장 간단한 방법은 불변 객체로 설계하는 것이다. 불변 객체

eversong

예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 스택 추적 정보를 자동으로 출력한다. 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다.예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하는 일은 아주 중요하다

eversong

메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보다.검상 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 javadoc의 @throw 태그를 사용하여 정확히 문서화 하자. 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자. ex)

eversong

수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 이는 윗 레벨 api를 오염 시킬 수 있다. 앞서 서술한 문제를 피하기 위해서는 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꾸어 주어야 한다. 이를 예외 번역이라고 한다

eversong

표준 예외를 재사용한다면 얻는것이 많다. 내가 작성한 API가 다른 사람이 익히고 사용하기 쉬워지고, 많은 프로그래머에게 익숙한 규약을 그대로 따르기 때문이다. 그리고 여러분의 코드 역시 읽기 쉬워진다.가장 많이 사용되는 예외이다. 호출자가 인수로 부적절한 값을 넘길

eversong

검사 예외는 제대로 활용하면 api와 프로그램의 질을 높일 수 있다. 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 물론 검사 예외를 사용하면, 오히려 쓰기 어려운 api가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를

eversong

자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러, 이렇게 세 가지를 제공하는데, 언제 무엇을 사용해야 하는지 헷갈려 하는 프로그래머들이 있다.호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 이는 검사 예외와 비

eversong

무슨 일을 하는지 절혀 알 수 없는 코드이다. 이 코드는 배열을 순회하는데, 끔찍한 방식으로 진행하고 있다. 무한 루프를 돌다가 배열의 끝에 도달해 예외가 발생하면 끝을 내는 것이다.이 코드는 성능 향상을 위해서 작성했다고 생각할 수 있지만, 표준 관용구(for-loo

eversong

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며 그중 많은 것이 자바 언어 명세에 기술되어 있다. 명명 규칙은 크게 철저와 문법, 두 범주로 나뉜다.철자 규칙은 패키지, 클래스, 인터페이스 등 변수의 이름을 다룬다. 이 규칙은 특별한 이유가 없는 한 반드시 따라야 한다.

eversong

최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다. 성능때문에 견고한 구조를 희생시키지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍쳐 자체가 최적화할 수 있는 길을