댕댕아 코딩하자

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 40. 메서드 시그니처는 신중하게 설계하라 1. 메서드 이름을 신중하게 골라라 - 네이밍 컨벤션을 따르는 것이 제일 베스트. - 이해하기 쉬우면서도 같은 패키지 안의 다른 이름들과 일관성이 유지되는 이름을 고르자 - 널리 합의된 사항에도 부합하는 이름을 고를 것. 2. 편의 메서드를 제공하는데 너무 열올리지 마라 - 모든 메서드는 맡은 일이 명확하고, 또 그것에 충실해야 한다. - 클래스에 메서드가 너무 많으면 학습, 사용, 테스트, 유지보수 등 모든 측면이 어려워진다. 특히 인터페이스의 경우는 메서드가 많으면 더 심각하다. - 클래스나 인터페이스가 수행해야 하는 동작 각각에 대해서 기능적으로 완전한 메서드를 제공하라. 3. 인자 리스트..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 38. 인자의 유효성을 검사하라 대부분의 메서드와 생성자는 인자로 사용할 수 있는 값을 제한한다. 값이 음수가 될 수 없다거나, null이 될 수 없다거나 등등등.. -> 이러한 제한들은 문서로 남겨야 할 뿐만 아니라 메서드 시작 부분에서 검사해야 한다. (오류(error)는 가급적 빨리 탐지해야 한다는 원칙에 의해) 이러한 검증을 생략하면 오류를 탐지하기 힘들어질 뿐만 아니라 문제 발생 지점을 파악하기도 곤란해진다. -> 메서드 앞부분에서 인자의 유효성을 검사하도록 하면 적절한 예외를 통해 깔끔하고 신속하게 오류를 검출할 수 있다. 하지만 만약 인자 유효성을 검사하지 않는다면 다음과 같은 문제가 생길 수 있다. 1. 처리 도중에 이상한..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 36. Override 애노테이션은 일관되게 사용하라 @Override 애노테이션은 메서드 선언부에만 사용할 수 있고, 상위 자료형에 선언된 메서드를 재정의한다는 사실을 표현한다. @Target(ElementType.METHOD) // 메서드에만 적용 가능 @Retention(RetentionPolicy.SOURCE) // 소스코드 까지만 적용 (.class 파일부턴 적용 X) public @interface Override { } 이 @Override 애노테이션을 일관되게 잘 사용하면 의외로 끔찍한 버그 발생을 방지할 수 있는 효과가 있다고 한다. - 개발자의 실수로 의도치 않게 Overriding이 아니라 Overloading이 되는..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. * (영어) ordinal: 서수(first, second...) cardinal: 기수(1, 2, 3...) 31. ordinal 대신 객체 필드를 사용하라 상당수의 enum 상수는 자연스럽게 int값 하나에 대응된다. 모든 enum에는 ordinal이라는 메서드가 있는데, enum 자료형 안에서 enum 상수의 위치를 나타내는 정수값을 반환한다. - 유지보수 관점에서 매우 끔찍한 결과를 불러올 수 있다. 가급적 절대 사용하면 안된다. - 상수의 순서를 변경하거나, 중간에 끼워넣기라도 하게 되면 순서를 기반으로 작성된 메서드에 모두 문제가 발생한다. 정 위치값이 필요하다면 ordinal을 사용하는 대신 상수 객체 필드에 별도로 정의해서..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 30. int 상수 대신 enum을 사용하라 열거타입(enumerated type)은 고정 개수의 상수들로 값이 구성되는 자료형이다. enum 자료형이 등장하기 이전에는 통상 int형의 상수를 정의해서 열거타입을 흉내냈다. public static final int APPLE_FUJI = 1; public static final int APPLE_PIPPIN = 2; public static final int ORANGE_NAVEL = 1; public static final int ORANGE_BLOOD = 2; 이러한 방법은 int enum 패턴이라고도 하는데, 형 안전성 관점에서도 그렇고 편의성 관점에서도 그렇고 문제점들이 있다. ..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 25. 배열 대신 리스트를 써라 배열은 제네릭 자료형과 중요한 두가지 차이점이 있다. 1. 배열은 공변 자료형(covariant)이고, 제네릭은 불변 자료형(invariant)이다. 2. 배열은 실체화(reifiable)되는 자료형이고, 제네릭은 삭제과정(erasure)을 통해 구현된다. 벌써부터 머리가 아프다. 공변 자료형이라니.. 공변 자료형이란 Sub가 Super의 하위 자료형이면 Sub[]도 Super[]의 하위 자료형이라는 것이다. 반면 불변 자료형은 Type1과 Type2가 있을 때 List은 List의 상위 자료형이나 하위 자료형이 될 수 없다. 이게 왜 중요해? 싶은데 그 이유는 바로 예외를 컴파일 시점에 잡아낼 수 있느냐..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 24. unchecked warning(무점검 경고)을 제거하라 unchecked 하니까 checked exception이랑 unchecked exception이 먼저 생각나는데 그런건 아니다. 컴파일 시에 발생하는 여러 Warning들(노란 느낌표) 이야기. - 잠재적 위험을 갖고있음을 뜻함 unchecked warning중 상당수는 쉽게 없앨 수 있는 것들이다. - 무점검 형변환 경고(unchecked cast warning) - 무점검 함수 호출 경고(unchecked method invocation warning) - 무점검 제네릭 배열 생성 경고(unchecked generic array creation warning) - 무점..

* 이펙티브 자바 2/E를 읽고 공부하기 위해 기록한 게시글입니다. 23. 새 코드에는 무인자 제네릭 자료형(raw type)을 사용하지 마라 자바에는 제네릭(Generic)이라는 개념이 있다. 먼 옛날 제네릭이 도입되기 이전에는 컬렉션에서 객체를 읽을때 마다 형변환(type cast)를 해줘야 했다. 그러다 누군가가 컬렉션에 엉뚱한 자료형 객체라도 넣어놓기라도 했으면 캐스팅 오류가 나고 만다. 하지만 제네릭을 사용하면 컬렉션에 넣을 객체의 자료형이 무엇인지를 컴파일러에게 알려줄 수 있다. -> 형변환 코드는 컴파일러가 알아서 만들어주고, 컬렉션에 잘못된 자료형의 객체를 넣으려는 시도는 컴파일 과정에서 미리 차단해준다. 제네릭 덕분에 안전하고 명료한 개발이 가능해진다! 선언부에 형인자(type param..