Hyerin Blog
일반적인 프로그래밍 원칙


57. 지역변수의 범위를 최소화하자.

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

  1. 지역변수 범위를 줄이는 가장 강력한 기법은 가장 처음 쓰일 때 선언하기 이다.
  2. 거의 모든 지역 변수는 선언과 동시에 초기화해야 한다.
  3. 메서드를 작게 유지하고 한 가지 기능에 집중하는 것



58. 전통적인 for문보다는 for-each문을 사용하자.

for(Iterator<Element> i = c.iterator(); i.hasNext();)

for(int i = 0; i < a.length; ++i)

위 코드는 while문보다는 낫지만 가장 좋은 방법은 아니다.
반복자, 인덱스 변수는 코드를 지저분하게 할 뿐 진짜 필요한 건 원소들 뿐이다.
for-each문을 사용하면 문제점들을 해결할 수 있다.

for(Element e : elements)


for-each를 사용할 수 없는 경우



61. 박싱된 기본 타입보다는 기본 타입을 사용하자.

각각 기본 타입에는 대응하는 참조 타입이 하나씩 있으며, 이를 박싱된 기본 타입이라고 한다.

int, double, boolean → Integer, Double, Boolean

오토박싱과 오토언박싱 덕분에 크게 구분하지 않고 사용할 수 있지만 그렇다고 차이가 없는 것은 아니다.
분명한 차이가 있으니 주의해서 선택해야 한다.


Auto Boxing vs Auto UnBoxing

Integer i = new Integer(5);
int j = i; // Auto UnBoxing

int k = 10;
Integer l = k; // Auto Boxing


기본타입 vs 참조타입


박싱된 기본타입에 == 연산자를 이용하여 비교하면 예상과는 다른 결과가 나올 수 있다.

Comparator<Integer> naturalOrder = (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);

Comparator<Integer> naturalOrder = (i, j) -> {
        int unBoxi = i;
    	int unBoxj = j;
    	return (unBoxi < unBoxj) ? -1 : (unBoxi == unBoxj ? 0 : 1); 
}


갑자기 발생하는 NullPointerException

public class Unbelievable {
    static Integer i;
    
    public static void main(String[] args) {
        if (i == 42) {
            System.out.println("믿을 수 없군");
        }
    }
}

i == 42를 검사하는 과정에서 NullPointerException을 던진다.

i는 Auto UnBoxing을 수행한다.
하지만 i는 null이기 때문에 Auto UnBoxing을 수행하는 과정에서 NullPointerException을 발생시키게 된다.


의도하지 않은 Auto Boxing으로 인한 성능저하

public static void main(String[] args) {
    Long sum = 0L;
    for (long i = 0L; i < Integer.MAX_VALUE; ++i) {
        sum += i; // sum이 UnBoxing되어 i와 연산되고 연산 후에 AutoBoxing되어 Long타입으로 변환된다.
    }
    System.out.println(sum);
}

위 코드는 sum을 Long으로 선언하였기 때문에 엄청난 성능상 안좋은 코드이다.
sum += i;를 수행하는 과정에서 sum이 long타입으로 UnBoxing되고
sum + i 연산이 이루어진다음 Long타입으로 AutoBoxing되기 때문이다.


박싱된 기본타입은 언제 사용해야 하는가?



64. 객체는 인터페이스를 사용해 참조하자.

예전에 매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라고 했었다.
이는 객체는 클래스가 아닌 인터페이스로 참조하라 까지 확장할 수 있다.

적합한 인터페이스만 있다면 매개변수뿐만 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하면 된다.
객체의 실제 클래스를 사용해야 할 상황은 오직 생성자로 생성할 때뿐이다.

// 좋은 예 - 인터페이스를 타입으로 사용 
Set<Son> sonSet = new LinkedHashSet<>();

// 나쁜 예 - 클래스를 타입으로 사용
LinkedHashSet<Son> sonSet = new LinkedHashSet<>();


인터페이스 타입 장점


인터페이스 타입의 단점


클래스를 참조해야 하는 경우



리플렉션보다는 인터페이스를 사용하자.

리플렉션 기능(java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다.
Class 객체가 주어지면 클래스 정보를 통해 아래와 같은 인스턴스를 가져올 수 있다.


리플렉션 단점


리플렉션은 무조건 쓰지 말아야 하는 걸까?



66. 네이티브 메서드는 신중히 사용하자.

자바 네이티브 인터페이스는 자바 프로그램이 네이티브 메서드를 호출하는 기술이다.
여기서 네이티브 메서드란 C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드를 말한다.

네이티브 메서드 주요 쓰임

성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 거의 권장하지 않는다.
자바 초기 시절이라면 이야기가 다르지만 JVM은 그동안 엄청난 속도로 발전 했다.
지금의 자바는 다른 플랫폼에 견줄만한 성능을 보인다.


네이티브 메서드의 단점

네이티브 메서드는 심각한 단점이 있다.
네이티브 언어가 안전하지 않아 사용하는 애플리케이션도 메머리 훼손 오류로부터 더 이상 안전하지 않다는 것이다.
디버깅도 어렵고 주의하지 않으면 속도가 오히려 느려질 수도 있다.
가비지 컬렉터가 네이티브 메모리는 자동 회수하지 못하며 추적조차 할 수 없다.



67. 최적화는 신중히 하자.

최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다.

성능때문에 견고한 구조를 희생시키지 말자.
빠른 프로그램보다는 좋은 프로그램을 작성하라 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍쳐 자체가 최적화할 수 있는 길을 안내해줄 것이다.

프로그램을 완성할 때까지 성능 문제를 무시하라는 뜻이 아니다.
구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍쳐의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. 따라서 설계단계에서 성능을 반드시 염두에 두어야 한다.

성능을 제한하는 설계를 피하라.
완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다.

API를 설계할 때 성능에 주는 영향을 고려하라.
public 타입을 가변으로 만들면, 불필요한 방어적 복사를 유발할 수도 있다. 합성으로 해결할 수 있는 문제를 상속 방식으로 해결하면 상위클래스에 영원히 종속되어 그 성능 제약까지 물려받게 된다.

다행히 잘 설계된 api는 성능도 좋은 게 보통이다. 그러니 성능을 위해 API를 애곡하는 건 매우 안 좋은 생각이다.



© 2022 Hyerin. All rights reserved.