item 67 Jung incheol - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

Effective Java 3e 아이템 67를 요약한 내용 입니다.

아래와 같은 최적화 격언이 있다.

(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다(심지어 효율을 높이지도 못하면서)
윌리엄 울프

(전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다.
도널드 크누스

최적화를 할 때는 다음 두 규칙을 따르라.
첫 번째, 하지 마라
두 번째, (전문가 한정)아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라
M. A. 잭슨

최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다. 빠른 프로그램보다는 좋은 프로그램을 작성하라. 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내해줄 것이다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다.

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

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

public 타입을 가변으로 만들면, 즉 내부 데이터를 변경할 수 있게 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다. 비슷하게, 컴포지션으로 해결할 수 있음에도 상속 방식으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 그 성능 제약까지도 물려받게 된다. 특정 구현체에 종속되게 하여, 나중에 더 빠른 구현체가 나오더라도 이용하지 못하게 된다.

java.awt.Component 클래스의 getSize 메서드를 생각해보자. Dimension 인스턴스를 반환할 뿐만 아니라 가변으로 설계되어 getSize를 호출하는 모든 곳에서 Dimension 인스턴스를 새로 생성해야만 한다.

public Dimension getSize() {
    return size();
}

@Deprecated
public Dimension size() {
    return new Dimension(width, height);
}

Dimension을 불변으로 만드는 게 가장 이상적이지만, getSize를 getWidth와 getHeight로 나누는 방법도 있다. 즉, Dimension 객체의 기본 타입 값들을 따로따로 반환하는 방식이다.

public Long getSize() {
    return this.getWight() * this.getHeight();
}

성능을 위해 API를 왜곡하는 건 매우 안 좋은 생각이다. API를 왜곡하도록 만든 그 성능 문제는 해당 플랫폼이나 아랫단 소프트웨어의 다음 버전에서 사라질 수도 있지만, 왜곡된 API와 이를 지원하는 데 따르는 고통은 영원히 계속될 것이다.