[Effective Java 3/E] 02. 객체 생성과 파괴 By starseat 2022-01-05 12:30:12 java/spring Post Tags # 생성자 대신 정적 팩터리 메서드 고려 ## 장점 1. 이름을 가질 수 있다. * ex) BigInteger.probablePrime 2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다. * Boolean.valueOf(boolean) 메서드는 객체를 아예 생성하지 않음. * (생성 비용이 큰) 같은 객체가 자주 요청되는 상황이라면 성능을 상당히 끌어올려줌. * Flyweight pattern 이 이와 비슷한 기법임. * 인스턴스 통제(instance-controlled) 클래스 * 클래스를 싱글턴(singleton) 또는 인스턴스화 불가(noninstantiable)로 만들 수 있음. * 불변 값 클래스에서 동치인 인스턴스가 단 하나뿐임을 보장 가능( a==b 일때만 a.equals(b) 성립) * 열거 타입은 인스턴스가 하나만 만들어짐을 보장 3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다. * 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 `유연성` 제공 * 이 유연성을 응용하여 구현 클래스를 공개하지 않고 그 객체를 반환할 수 있어 API를 작게 유지 가능 * java 8부터 가능(그 이전버전은 책 p10 참조) * java 8부터 인터페이스가 정적 메서드를 가실 수 없다는 제한이 풀림. * 정적 메서드를 구현하기 위해서는 별도의 package-private 클래스를 두어야 할 수 있음. * java8에서는 인터페이스에는 public 정적 멤버만 허용 * java9에서는 private 정적 메서드까지 허락정적 필드와 정적 멤버 클래스는 여전히 public 4. 입력 매개변수에 따라 매번 다른 클래스의 객체 반환 가능 * 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없음. * OpenJDK 에서는 원소의 수에 따라 두가지 하위 클래스 중 하나의 인스턴스 반환 (EnumSet 클래스) * 원소가 64개 이하: long 변수 하나로 관리하는 RegularEnumSet 의 인스턴스 반환 * 원소가 65개 이상: long 배열로 관리하는 JumboEnumSet 의 인스턴스 반환 5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. * 프레임워크를 만드는 근간이 됨. (jdbc(Java Database Connectivity)가 대표적) * 서비스 제공자 프레임워크에서의 제공자(provider)는 서비스의 구현체임. * 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여 클라이언트를 구현체로부터 분리해줌. * 서비스 제공자 프레임워크의 3가지 핵심 컴포넌트 * 서비스 인터페이스(service interface): 구현체의 동작 정의 * 제공자 등록 API(provider registration API): 제공자가 구현체 등록할떄 사용 * 서비스 접근 API(service access API): 클라이언트가 서비스의 인스턴스를 얻을떄 사용 ## 단점 1. 상속을 하려면 public 이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다. 2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다. * 정적 팩터리 메서드에 흔히 사용하는 명명 방식 | 키워드 | 설명 | 예 | | --------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- | | `from` | 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 | Date d = Date.from(instant); | | `of` | 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 | Set faceCards = EnumSet.of(JACK, Q!UEEN, KING); | | `valueOf` | from 과 of 의 더 자세한 버전 | BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE); | | `instance` 혹은 `getInstance` | (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지 않음. | StackWalker luke = StackWalker.getInstance(options); | | `create` 혹은 `newInstance` | instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장 | Object newArray = Array.newInstance(classObject, arrayLen); | | `getType` | getInstance 와 같으나 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할떄 쓰임. "Type"은 팩터리 메서드가 반환할 객체의 타입임 | FileStore fs = Files.getFileStore(path) | | `newType` | newInstance 와 같으나 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할떄 쓰임. "Type"은 팩터리 메서드가 반환할 객체의 타입임 | BufferedReader br = Files.newBufferedReader(path); | | `type` | getType 과 newType 의 간결한 버전 | List litany = Collections.list(legacyLitany); | # 생성자에 매개변수가 많다면 빌더를 고려하라 ## 생성자 생성 방법 - 점층적 생성자 패턴(telescoping constructor pattern): 멤버 변수 할당 수 만큼 생성자 생성 - 자바 빈즈 패턴(JavaBeans pattern): 매개변수가 없는 생성자로 객체 생성 후 setter 로 값 세팅 - 빌더 패턴(Builder pattern): 강추!!!! (매개변수가 4개 이상이 되어야 값어치 함) ### 빌더패턴 클래스 생성 예 ```java public class Temp { private final String id; private final String phone; private final String name; private final String address; private final int age; public static class Builder { // 필수 매개변수 private final String id; private final String phone; // 선택 매개변수 private final String name = "";; private final String address = ""; private final age = 0; public Builder(String id, String phone) { this.id = id; this.phone = phone; } public Builder name(String val) { name = val; return this;} public Builder address(String val) { address = val; return this; } public Builder age(int val) { age = val; return this; } public Temp build() { return new Temp(this); } } private Temp(Builder builder) { id = builder.id; phone = builder.phone; name = builder.name; address = builder.address; age = builder.age; } } ``` ### 빌더패턴 클래스 사용 예 ```java Temp temp = new Temp.Builder("1", "01012345678").name("tester").address("seoul").age(30).build(); ``` ## 빌더패턴 확장 - 빌더패턴은 계층적으로 설계된 클래스와 함꼐 쓰기 좋음. ```java // 뼈대가 되는 부모 클래스 public abstract class Pizza { public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE } final Set toppings; abstract static class Builder> { EnumSet toppings = EnumSet.noneOf(Topping.class); public T addTopping(Topping topping) { toppings.add(Objects.requireNonNull(topping)); return self(); } abstract Pizza build(); // 하위 클래스는 이 매서드를 재정의(overriding) 하여 "this"를 반환하도록 함. // self 타입이 없는 자바를 위한 '시뮬레이트한 셀프 타입(simulated self-type)' 관용구라 함 protected abstract T self(); } Pizza(Builder> builder) { toppings = builder.toppings.clone(); } } // 계층적 빌더 사용 public class NYPizza extends Pizza { public enum Size {SMALL, MEDIUM, LARGE } private final Size size; public static class Builder extends Pizza.Builder { private final Size size; public Builder(Size size) { this.size = Objects.requireNonNull(size); } @Override public NYPizza build() { return new NYPizza(this); } @Override protected Builder self() { return this; } } private NYPizza(Builder builder) { super(builder); size = builder.size; } } public class Calzone extends Pizza { private final boolean sauceInside; public static class Builder extends Pizza.Builder { private boolean sauceInside = false; // 기본값 public Builder sauceInside() { sauceInside = true; return this; } @Override public Calzone build() { return new Calzone(this); } @Override protected Builder self() { return this; } } private Calzone(Builder builder) { super(builder); sauceInside = builder.sauceInside; } } # 사용 예 NYPizza pizza = new NYPizza.Builder(SMALL).addTopping(SAUSAGE).addTopping(ONION).build(); Calzone calzone = new Calzone.Builder().addTopping(HAM).sauceInside().build(); ``` # private 생성자나 열거 타입으로 싱글턴임을 보증하라 - 싱글턴(singleton): 인스턴스를 오직 하나만 생성할 수 있는 클래스 ## 싱글턴 생성 예 ```java // 생성 예 1) public static final 필드 방식의 싱글턴 public class Temp { public static final Temp INSTANCE = new Temp(); // public 이나 protected 생성자가 없으므로 // 초기화될 때 만들어진 인스턴스가 전체 시스템에서 하나뿐임을 보장 private Temp() { ... } public void test() { ... } } // 생성 예 2) 정적 팩터리 방식의 싱글턴 public class Temp { private static final Temp INSTANCE = new Temp(); private Temp() { ... } public static Temp getInstance() { return INSTANCE; } public void test() { ... } } ``` ## 싱글턴 생성 확장 - 모든 인스턴스 필드를 일시적(transient)이라고 선언하고 readResolve 메서드 제공해야 함. - 이렇게 하지 않으면 직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 생성됨. - 위 생성 예에서라면 가짜 `Temp` 가 생성됨. ```java public class Temp { private static final Temp INSTANCE = new Temp(); private Temp() { ... } public static Temp getInstance() { return INSTANCE; } public void test() { ... } // 싱글턴임을 보장해주는 readResolve 메서드 private Object readResolve() { // '진짜' Temp를 반환하고, 가짜 Temp는 가바지 컬렉터에 맡김 return INSTANCE; } } ``` ## 싱글턴 생성 열거타입 - 대부분 상황에서는 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법임. - 단, 만들려는 싱글턴이 Enum 외의 클래스를 상속해야 한다면 사용할 수 없음. ```java public enum Temp { INSTANCE; public void temp() { ... } } ``` # 인스턴스화를 막으려거든 private 생성자를 사용하라 - 정적 메서드와 정적 필드만을 담은 클래스를 만들때 사용 - java.lang.Math 와 java.util.Arrays 등. - 이 방식은 상속을 불가능하게 하는 효과도 있음. ```java public class UtilityClass { // 기본 생성자가 만들어지는 것을 막음(인스턴스화 방지) private UtilityClass() { // 꼭 AssertionError 를 던질 필요는 없지만 실수로라도 클래스 안해서 생성자 호출 방지 throw new AssertionError(); } ... } ``` # 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 - 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않음. ```java public class SpellChecker { private final Lexicon dictionary; public SpellChecker(Lexicon dictionary) { this.dictionary = Objects.requireNonNull(dictionary); } public boolean isValid(String word) { ... } public List suggestions(String typo) { ... } } ``` # 불필요한 객체 생성을 피하라 - `String s = new String("temp");` 보단 `String s = "temp";` - `Boolean(String)` 생성자 대신 `Boolean.valueOf(String)` - 자주 사용되는 정규식은 메서드로! ```java // 문자열이 유효한 로마 숫자인지 확인 // 이거보단 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})$"); } // 이거로! // 책에선 6.5배 정도 빨라졌다고 합니다! public class RomanNumerals { private static final Pattern ROMAN = Pattern.compile( "^(?=.)M*(C[MD]|D?:C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]V?I{0,3})$" ) static boolean isRomanNumeral(String s) { return ROMAN.matcher(s).matches(); } } ``` - 불필요한 객체를 만들떄는 오토박싱(auto boxing) 도 있음. - Boxing 된 타입 보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의! ```java private static long sum() { Long sum = 0L; // 책에서는 6.3 초 return 까지 걸린다고 함. // long sum = 0L; // 이렇게 sum 변수를 Long 에서 long 으로 변경하는 것만으로도 0.59초로 단축됨. for(loing i=0; i<=Integer.MAX_VALUE; i++) { sum += i; } return sum; } ``` # 다 쓴 객체 참조를 해제하라 - 다 쓴 참조(obsolete reference) 를 정리하지 않으면 가비지 컬렉터가 회수하지 않음. -> 메모리 누수 발생 - 참조를 담은 변수를 유효 범위 밖으로 밀어내는게 다 쓴 참조 해제에 좋음. - 다 쓴 객체 참조를 null 처리하는 일은 예외적인 경우여야 함. (모든 객체를 다 쓰자마자 null 처리 X) - 리스너(.listener) 혹은 콜백(callback) 도 메모리 누수의 주범이니 조심! # try-finally 보다는 try-with-resources 를 사용하라 - 꼭 회수해야 하는 자원이 있을경우 try-with-resources 를 사용하자! ## try-finally - 전통적으로 사용되었던 try-finally ```java static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } ``` - 자원이 둘 이상일 경우 try-finally 의 지저분함 ```java static void copy(String src, String dst) throws IOException { InputStream in = new FileInputStream(src); try { OutputStream out = new FileOutputStream(dst); try { byte[] buf = new byte[BUFFER_SIZE]; int n; while( (n = in.read(buf) ) >= 0) out.write(buf, 0, n); } finally { out.close(); } } finally { in.close(); } } ``` ## try-with-resources - java 7 부터 가능 - 이 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야함. - 이미 수많은 라이브러리들이 구현되거나 확장해둠. - 자원이 하나일 경우 ```java static String firstLineOfFile(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } } ``` - 자원이 둘 이상일 경우 ```java static void copy(String src, String dst) throws IOException { try ( InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dst) ) { byte[] buf = new byte[BUFFER_SIZE]; int n; while( (n = in.read(buf) ) >= 0) out.write(buf, 0, n); } } ``` - try-with-resources 에 catch 절 추가 ```java static String firstLineOfFile(String path, String defaultVal) { try ( BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } catch (IOException e) { return defaultVal; } } ``` Previous Post [Effective Java 3/E] 01. 들어가기 Next Post [Effective Java 3/E] 04. 클래스와 인터페이스