[이펙티브 자바] 9장 : 일반적인 프로그래밍 원칙

지역변수, 제어구조, 라이브러리, 데이터 타입, 리플렉션, 네이티브 메서드에 대해 알아보자

아이템 57 : 지역변수의 범위를 최소화하라

범위를 최소하는하는 방법

1. 지역변수의 범위를 줄이는 가장 강력한 방법은 ‘가장 처음 쓰일 때 선언하기'이다.
2. 거의 모든 지역변수는 선언과 동시에 초기화 해야한다.
3. 메서드를 최대한 작게 유지하고 한 가지 기능에 집중해라. (다른 기능에서 접근하지 못하도록)

범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성이 낮아진다.

예시

• 반복 변수의 값을 반복문 종료후에도 써야하는 상황이 아니라면 while문보다는 for문이 낫다.
  • for문은 반복 변수의 범위가 for괄호안으로 제한된다.
• try-catch 사용 시 변수를 초기화하는 과정에서 검사 예외를 던질 가능성이 있다면 try블록 안에서 초기화 해야만 한다. 만약, 변수를 try문 바깥에서 사용해야 한다면 선언은 try문 밖에 해둬야 한다.

아이템 58 : 전통적이 for문보다는 for-each문을 사용하라

for문은 while문보다는 낫다고 이전 아이템에서 말했지만 가장 좋은 방법은 아니다.

for가 좋지않은이유

• 자주 사용하게 되는 인덱스 변수는 실수를 유발하게 되고 이 실수를 컴파일러가 잡아준다는 보장이 없다.
• 또한 컬렉션인지 배열인지에 따라 코드형태가 달라진다.

향상된 for-each문을 사용하라

• 반복자와 인덱스 변수를 사용하지 않으므로 인덱스 실수가 나지 않고 코드가 깔끔해진다.
• 하나의 관용구로 컬렉션과 배열을 순회한다.

		public static void main(String[] args) {
        List<Card> deck = new ArrayList<>();
        
				// 실수로 인한 오류발생
        for (Iterator<Suit> i = suits.iterator(); i.hasNext(); )
            for (Iterator<Rank> j = ranks.iterator(); j.hasNext(); )
                deck.add(new Card(i.next(), j.next()));

        // 코드 58-7 컬렉션이나 배열의 중첩 반복을 위한 권장 관용구 (349쪽)
        for (Suit suit : suits)
            for (Rank rank : ranks)
                deck.add(new Card(suit, rank));
    }

인덱스를 사용한 for문은 실수를 유발해 오류가 발생할 수 있으니 for-each문을 사용하자

하지만, for-each문을 사용할 수 없는 상황도 존재한다.

• 파괴적 필터링 : 컬렉션을 순회하면서 선택된 원소를 제거해야 할 떄
  • 반복자의 remove() 사용
• 변형 : 리스트나 배열을 순회하면서 그 원소의 값 일부 혹은 전체를 교체해야 할 때
  • 반복자나 인덱스를 사용해야함
• 병렬 반복 : 여러 컬렉션을 병렬로 순회해야 한다면 각 반복자와 인덱스 변수를 사용해 엄격하고 명시적으로 해야 한다.

for-each문은 컬렉션과 배열은 물론이고 ‘Iterable’ 인터페이스를 구현한 객체라면 무엇이든 순회가 가능하다.

아이템 59 : 라이브러리를 익히고 사용하라

널리 쓰이고 오랜 기간 전부터 개발된 random값 뽑기같은 기능은 직접 만드는 것보다 라이브러리를 이용하는 것이 훨씬 정확하고 효율적이다.

• 표준 라이브러리를 사용하면 훨씬 뛰어난 전문가들의 경험을 활용할 수 있다.
• 우리는 이제 필요한 ‘핵심 비즈니스 로직'에만 집중하면 된다.
• 라이브러리 제작자들의 꾸준한 ‘성능 향상’
• 기능이 점점 많아진다.
• 많은 사람들이 공유해서 쓰기 때문에 사람들에게 낯익은 코드가 되고 유지보수하기 좋은 코드가 된다.

java.lang, util, io와 그 하위 패키지에 익숙해지자. 또한 java.uti.concurrent,에도 익숙해지면 좋다. 없는 것은 구현해야겠으나 이미 개발된 것은 가져다쓰는 것이 훨씬 효율적이다.

아이템 60 : 정확한 답이 필요하다면 float와 double을 피하라

float와 double 타입은 ‘근사치'로 계산하도록 설계되었다. 따라서 금융 관련 계산과는 맞지 않다.

숫자가 크지 않다면 int, long을 사용하고 그렇지 않다면 BigInteger를 사용할 수 있다.

아이템 61 : 박싱된 기본 타입보다는 기본 타입을 사용하라

• 박싱 타입은 ‘식별성' + ‘값'을 속성으로 갖는다.
• ‘==’ 비교 시 ‘식별성'을 이용하므로 값이 같아도 다르다고 판단할 수 있다. (오류)
• 기본 타입과 박싱된 타입을 혼용한 연산에서는 박싱된 타입의 박싱이 자동으로 풀린다.
• 반복문에서 박싱을 잘못쓰면 심각한 성능문제가 발생한다.

아이템 62 : 다른 타입이 적절하다면 문자열 사용을 피하라

문자열은 텍스트를 표현하도록 설계되었지만 다른 용도로 쓰이는 경향이 있다...

“문자열은 다른 값 타입을 대신하기에 적합하지 않다”

• 문자열은 열거 타입을 대신하기에 적합하지 않다.
  • 상수 열거는 문자열보다 열거 타입이 낫다 (아이템 34)
• 문자열은 혼합 타입을 대신하기에 적합하지 않다.
  • 여러 요소의 데이터가 혼합된 것을 문자열로 표현하는 것은 좋지 않다.
  예) String compoundKey = className + “#” + i.next();
• 문자열을 파싱해야하고 String의 기능에만 의존해야한다.
• 문자열은 권한을 표현하는데 적합하지 않다.

현재 상황에 더 적합한 타입이 있다면 문자열을 버리고 사용하라.

아이템 63 : 문자열 연결은 느리니 주의하라

문자열 연결 연산자로 문자열 n개를 잇는 시간은 n^2에 비례한다.

• 문자열은 불변이기에 연결할 경우 양쪽의 내용을 복사해야만 한다.

잦은 연결은 하고 싶고 성능은 포기하기 싫다면 ‘StringBuilder’를 사용하자.

아이템 64 : 객체는 인터페이스를 사용해 참조하라

아이템 51에서 매개변수 타입으로 ‘클래스가 아닌 인터페이스'를 사용하라고 했다.

이는 **“객체는 클래스가 아닌 인터페이스로 참조하라"**고 까지 확장할 수 있다.

적합한 인터페이스만 존재한다면 ‘반환값, 변수, 필드’ 모두 를 인터페이스 타입으로 선언하라

⇒ 인터페이스를 사용하면 프로그램이 훨씬 유연해진다. 변경이 발생했을 때 팩토리나 필요한 구현체를 교체해주기만 하면된다.

조건

• 새로운 클래스는 반드시 인터페이스의 모든 기능을 구현해야한다. (제공해야한다)’

적합한 인터페이스가 없다면 클래스의 계층구조 중 필요한 기능을 만족하는 가장 덜 구체적인(상위의) 클래스를 타입으로 사용하자.

아이템 65 : 리플렉션 보다는 인터페이스를 사용하라

리플렉션 장점

리플렉션(java.lang.reflect)를 이용하면 임의의 클래스에 접근할 수 있다.

• 클래스의 생성자, 메서드, 필드, 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다.
• 실제 생성자, 메서드, 필드를 조작할 수도 있다.
• 컴파일 시에 존재하지 않은 클래스도 이용할 수 있다.

리플렉션 단점

• 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다. (+ 예외 검사)
• 리플렉션을 이용하면 코드가 지저분하고 장황해진다
• 성능이 떨어진다. 리플렉션을 통한 메서드 호출은 일반 메서드 호출보다 느리다.

리플렉션은 아주 제한된 형태로 사용하는 것이 좋다.

• 컴파일 타임에 이용할 수 없는 클래스를 사용해야 한다면 리플렉션은 생성에만 쓰고 인스턴스는 인터페이스나 상위 클래스로 참조해 사용하자.

아이템 66 : 네이티브 메서드는 신중히 사용하라

성능 개선을 목적으로 사용하지마라. JVM은 이미 엄청나게 발전해서 충분히 빠르다.

자바 네이티브 인터페이는 자바 프로그램이 네이티브 메서드를 호출하는 기술.

• 네이티브 메서드 : C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드

성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 거의 권장하지 않는다.

• 네이티브 메서드는 안전하지 않고, 이식성도 낮고, 디버깅도 어렵다. 가비지 컬렉터가 메모리 회수하지 못한다.

꼭 필요하다면 최소한으로 사용하고 철저히 테스트해서 신중하게 사용하라.

아이템 67 : 최적화는 신중히 하라

빠른 프로그램보다는 좋은 프로그램을 작성하라

성능 때문에 견고한 구조를 희생해서는 안된다.

최적화 격언...

‘첫번째, 하지마라, 두번째, 아직하지마라, 완전히 명백하고 최적화된 해법을 찾을 때까지는 하지마라’

먼저 설계시 API, 네트워크프로토콜, 영구저장용데이터포맷 사용 시 성능을 염두에 둬라. 구현 후 성능이 나오지 않는다면 그 때 원인을 찾아 최적화를 수행하라.

변경 후에는 항상 성능을 측정해라.

아이템 68 : 일반적으로 통용되는 명명 규칙을 따르라

우리가 자주 보고 겪고 있는 필드, 메서드 등의 명명은 체화시키도록 하자. 표준 명명 규칙을 따르면 나와 다른 사람들도 명명 규칙에 대해 이해하기 쉬워진다.