자바 라이브러리에는 close 메서드로 직접 닫아줘야하는 자원이 많다. ex) InputStream, OutputStream, java.sql.Connection 자원 닫기는 예측할 수 없는 성능 문제로 이어질수있다. try-finally 전통적으로 자원을 닫는 수단으로 사용하였다. 예외가 발생하거나 메서드에서 반한되는 경우를 포함해서 말이다. //자원이 하나인 경우 static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } //자원이 둘 이..
finalizer와 cleaner 자바가 제공하는 두가지 객체 소멸자다. finalizer는 예측할 수없고 위험할 수 있어 일반적으로 불필요하여 자바9 이후 deprecataed 되었다. 그 대안인 cleaner는 finalizer보단 덜하지만 여전히 예측할 수 없고 느려서 불필요하다. c++의 파괴자(destructor) 와는 다른 개념이다. c++에서 파괴자는 비메모리 자원을 회수하는 용도르 쓰이지만, 자바에서는 try-with-resources나 try-finally를 사용하여 해결한다. finalizer와 cleaner의 부작용 finalizer와 cleaner는 즉시 수행된다는 보장이 없어 제때 실행되어야 하는 작업은 절대 할 수 없다. ex) 파일 닫기를 finalizer와 cleaner에 맡..
자바의 가비지 컬렉터는 알아서 다 쓴 객체를 회수해간다. 그럼에도 메모리 관리에 신경써야한다. public class Stack { private static final int DEFAULT_INITAL_CAPACITY = 16; private Obejct[] elements; private int size = 0; public Stack() { elements = new Object[DEFAULT_INITAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[size++]; } public Object pop() { if (size == 0) { throw new EmptyStackException(); } return eleme..
객체의 재사용 똑같은 기능의 객체를 매번 생성하는 것보다 객체 하나를 재사용하는 것이 나을 때가 많음 생성자 대신 정적 팩터리 메서드를 사용하여 불필요한 객체 생성을 피할 수 있음 ex) Boolean.valueOf(String) 그런데 생성 비용이 아주 비싼 객체도 있다. 이런 객체를 반복해서 필요할 때는 캐싱해서 재사용을 권장한다. static boolean isRomanNumeral(String s) { return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$"); } 위의 코드는 String.matches 로 정규표현식을 통해 문자열 형태를 확인하는 코드이다. 그런데, 이 메서드가 내부에서 만드는 Pattern..
클래스가 하나 이상의 자원에 의존할때 이런 클래스를 정적 유틸리티 클래스나 싱글턴 클래스로 만드는 경우 // 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다 public class SpellChecker{ private static final Lexicon dictionary = ...; // 사전에 의존 private SpellChecker() {} // 객체 생성 방지 public static boolean isValid(String word){...} public static List suggestions(String typo){...} } // 싱글턴을 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다 public class SpellChecker{ private static..
정적 멤버만 담은 유틸리티 클래스 정적 메서드와 정적 필드만을 담은 클래스 java.lang.Math, java.util.Arrays, java.util.Collections final 클래스와 관련한 메서드를 모아 놓을 때 사용 인스턴스화 막기 유틸리티 클래스는 인스턴스로 만들어 쓰려 설계한것이 아님 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어서 인스턴스화가 가능하기 때문에 인스턴스화를 막을 수 없음 추상 클래스로 만들면 하위 클래스를 만들어 인스턴스화가 가능하기 때문에 인스턴스화를 막을 수 없음 ❗️ private 생성자를 추가하여 인스턴스화를 막을 수 있다. (클래스 바깥에서 접근할 수 없음) 이는 상속도 불가능하게 한다.(생성자가 접근이 불가능하기 때문)
싱글턴(singleton) 인스턴스를 오직 하나만 생성할 수 있는 클래스 무상태 객체, 설계상 유일해야하는 시스템 컴포넌트 클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. 싱글턴 인스턴스를 mock 구현으로 대체할 수 없기 때문 public static final 필드 방식의 싱글턴 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { ... } public void leaveTheBuilding() { ... } } private 생성자는 public static final 필드인 Elvis.INSTANCE를 초기화할때 한번만 호출됨. public 이나 prot..
정적 팩터리와 생성자에는 선택적 매개변수가 많을때 적절한 대응이 어렵다. 점층적 생성자 패턴 ( 확장의 어려움) public class NutritionFacts { private final int servingSize; // 필수 private final int servings; // 필수 private final int calories; // 선택 private final int fat; // 선택 private final int sodium; // 선택 private final int carbohydrate; // 선택 public NutritionFacts(int servingSize, int servings) { this(servingSize, servings, 0); } public Nutri..