개발서적

    [Effective Java] 예외는 진짜 예외 상황에만 사용하라

    예외의 잘못된 사용 다음은 예외를 잘못 사용한 예시이다. try { int i = 0; while(true) range[i++].climb(); }catch (ArrayIndexOutOfBoundException e) { } 이 코드의 문제는 다음과 같다. 전혀 객관적이지 않다. 다음과 같이 작성하면 모든 사람이 직관적으로 이해할 수 있다. for (Mountain m : range) m.climb(); 제대로 동작하지 않을 수 있다. 반복문안에 잘못된 코드가 숨어져 있다면 흐름 제어에 쓰인 예외가 이 버그를 숨겨 디버깅을 더 어렵게 만든다. 예외는 필요할 때만 사용하자 예외는 오직 예외 상황에서만 사용해야 한다. 절대로 일상적인 제어 흐름용으로 쓰여서는 안 된다. 이 원칙은 API 설계에도 적용된다. ..

    [Effective Java] 일반적으로 통용되는 명명 규칙을 따르라

    자바의 명명 규칙은 크게 철자와 문법 두 범주로 나뉜다. 철자 규칙 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 패키지와 모듈 각 요소를 점(.)으로 구분하여 계층적으로 짓는다. 예외적으로 표준 라이브러리와 선택적 패키지들은 각각 java와 javax로 시작한다. 패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이뤄진다. 각 요소는 일반적으로 8자 이하의 짧은 단어로 한다. utilities보다는 util처럼 의미가 통하는 약어가 좋다. 클래스와 인터페이스 열거 타입과 애너테이션을 포함해 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지며, 각 단어는 대문자로 시작한다(List, FutherTask). 여러 단어의 첫 글자만 딴 약어나 m..

    [Effective Java] 최적화는 신중히 하라

    빠른 프로그램보다는 좋은 프로그램을 작성하자 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 제공한다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다. 좋은 설계를 하는 방법 성능을 제한하는 설계를 피하자. 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다. -> API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 API를 설계할 때 성능에 주는 영향을 고려하라. -> public 타입을 가변으로 만들면, 불필요한 방어적 복사를 수없이 유발할 수 있다. -> 컴포지션으로 해결할 수 있음..

    [Effective Java] 네이티브 메서드는 신중히 사용하라

    자바 네이티브 인터페이스와 네이티브 메서드 자바 네이티브 인터페이스는 자바 프로그램이 네이티브 메서드를 호출하는 기술이다. 여기서 네이티브 메서드란 C나 C++같은 네이티브 프로그래밍 언어로 작성한 메서드를 말한다. 네이티브 메서드의 쓰임 레지스트리 같은 플랫폼 특화 기능을 사용하는 경우. 네이티브 코드로 작성된 기존 라이브러리를 사용하는 경우 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성하는 경우 -> 성능 개선을 목적으로 네이티브 메서드를 사용하는 것은 권장하지 않는다. 네이티브 언어가 안전하지 않으므로 네이티브 메서드를 사용하는 애프릴케이션도 메모리 훼손으로부터 안전하지 않다. 자바보다 플랫폼을 많이 타서 이식성이 낮다. 디버깅이 어렵다 가비지 컬렉터가 네이티브..

    [Effective Java] 리플렉션보다는 인터페이스를 사용하라

    리플렉션보다는 인터페이스를 사용하라 리플렉션을 사용하면 프로그램에서 임의의 클래스에 접근할 수 있다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 인스턴스를 가져올 수 있고 이 인스턴스들을 이용해 실제 생성자, 메서드, 필드를 조작할 수 있다. 리플렉션을 이용하면 컴파일 당시에 존재하지 않던 클래스도 이용할 수 있지만 많은 단점을 가지고 있다. 리플렉션의 단점 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다 리플렉션을 이용하면 코드가 지저분하고 장황해진다. 성능이 떨어진다. 리플렉션의 사용 리플렉션은 아주 제한된 형태로만 사용해야 그 단점을 피하고 이점만 취할 수 있다. -> 컴파일타임에 이용할 수 없는 클래스를 사용해야만 하는 프로그램은 비록 컴파일타임이라도 적절한..