책

디미터 법칙은 잘 알려진 휴리스틱으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 습관적 getter, setter 문단에서 봤듯이, 객체는 자료를 숨기고 함수를 공개한다. 좀 더 정확히 표현하면, 디미터 법칙은 “클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다”고 주장한다. 클래스 C f가 생성한 객체 f 인수로 넘어온 객체 C 인스턴스 변수에 저장된 객체 하지만 위 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안 된다. 다시 말해, 낯선 사람은 경계하고 친구랑만 놀라는 의미이다. 아래는 예시이다. final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath(); 흔히 위와 같..

아래 두 코드 예시를 보자 public class Point { public double x; public double y; } public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); } 두 번째 코드는 자료 구조 이상을 표현한다. 접근 정책을 강제하고 추상적이지만 자료구조를 명백하게 표현한다. 첫 번째 코드는 getter, setter가 노출되고 개별적으로 변수 값을 읽고 설정하게 강제한다. 변수가 private으로 정의되고 getter, setter가 있다면 별..

이펙티브 자바 골라보기 Object 클래스에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의(overriding)를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다. 그래서 Object를 상속하는 클래스, 즉 모든 클래스는 이 메서드들을 일반 규약에 맞게 재정의해야 한다. 하지만 잘못 구현하면 이 규약을 준수한다고 가정하여 설계된 클래스들을 오동작하게 만들 수 있으므로, 주의를 기울여야 한다. equals()를 꼭 재정의해야 할까 가장 쉬운 방법은 아예 재정의하지 않는 것이다. 그냥 두면 해당 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. 다음 상황들 중 하나에 해당한다면 재정의하지 않는 것..

많은 클래스가 하나 이상의 자원에 의존한다. 가령 맞춤법 검사기는 사전(dictionary)에 의존하는데, 이런 클래스를 정적 유틸리티 클래스로 구현한 모습을 드물지 않게 볼 수 있다. // 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다 public class SpellChecker { private static final Lexicon dictionary = ...; // 인스턴스화 방지 private SpellChecker() {} public static boolean isValid(String word) {...} public static List suggestions(String typo) {...} } // 비슷하게 싱글턴을 잘못 사용한 예 public class Spel..

인스턴스화를 막으려거든 private 생성자를 사용하라. 이따금 단순히 정적 메서드와 정적 필드만을 담은 클래스가 필요할 때가 있다. 예를 들어 java.lang.Math와 java.util.Arrays 처럼 기본 타입 값이나 배열 관련 메서드들을 모아놓거나 java.util.Collections 처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓을 수도 있다. 또한 final 클래스를 상속해서 하위 클래스에 메서드를 넣는 건 불가능하기 때문이다. 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한게 아니기 때문에 기본 생성자가 자동으로 생성되지 않도록 해야 한다. 해당 클래스를 추상 클래스로 만드는 것으로는 인스턴스화를 만들 수 없다. 하위 클래스를 만..

싱글턴(singleton)이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다. 싱글턴의 전형적인 예로는 함수와 같은 무상태 객체나 설계상 유일해야 하는 시스템 컴포넌트를 들 수 있다. 그런데 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 타입을 인스턴스로 정의한 다음 그 인터페이스를 구현해서 만든 싱글턴이 아니라면 싱글턴 인스턴스를 가짜(Mock) 구현으로 대체할 수 없기 때문이다. 싱글턴을 만드는 방식은 보통 둘 중 하나다. 일단 두 방식 모두 생성자는 private으로 감춰두고, 유일한 인스턴스에 접근할 수 있는 수단으로 public static 멤버를 하나 마련해둔다. public static final 필드 방식의 싱글턴 public class El..