이번 장에서는 객체의 생성과 파괴에 대해서 다루게 된다. 올바른 때에 생성하는 법, 올바른 때에 파괴하는 법, 불필요한 생성을 피하는 법 등을 다루게 된다.
자바를 배우기 시작한 얼마 안되는 초심자라면, 객체 생성 시에 생성자를 사용할 것이다.
class Person {
private String name;
public Person(String name) { // 이름을 받고 있는 생성자. 여기서 받는 개인정보가 점점 추가된다면..?
this.name = name;
};
}그러나 매개 변수 등이 증가하고, 같은 역할을 하는 객체에 대해서 계속해서 생성자를 사용하여 새로 생성하게 된다면, 코드가 복잡해지고 성능이 저하될 것이다. 생성자 대신에 사용하는 몇 가지 패턴이 있는데, 여기서는 정적 팩터리 메서드에 대해 설명하고 있다. (여기서 설명하는 정적 팩터리 메서드는 디자인 패턴에서 말하는 팩터리 패턴과 아예 다른 개념이다.)
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}위 코드는 일반 타입인 boolean을 객체 타입인 Boolean 으로 박싱하는 코드이다. 이때 valueOf 라는 정적 메서드를 통해서 Boolean 객체를 반환하게 된다. 이와 같이 자바에서는 생성자를 사용하지 않고도 객체를 만들어 낼 수 있다. 이와 같이 정적 팩터리 메서드를 사용하면 좋은 장점이 다섯가지나 있다.
장점 1. 이름을 가질 수 있다.
생성자는 그 생성자에 넘기는 매개변수와 그 자체만으로는 객체의 특성을 제대로 설명할 수 없다. 그러나 위에서 살펴본 valueOf 메서드와 같은 정적 팩터리 메서드는 이름을 가지고 있으며, 그 이름으로 역할과 반환되는 객체에 대한 설명을 명시적으로 할 수 있다.
장점 2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.
위의 valueOf 와 같은 메서드는 객체를 리턴하지만, 인스턴스를 새로 생성하지는 않는다. 매개변수 b 의 값에 따라서 Boolean.TRUE 혹은 Boolean.FALSE 이라는 정적 영역의 값, 즉 이미 만들어져 있는 값을 리턴할 뿐이다. 이렇게 함으로서 자주 호출되는 객체에 대해서 성능을 상당히 끌어올릴 수 있다. 플라이웨이트 패턴도 이와 비슷한 기법이라고 할 수 있다.
장점 3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
이 능력은 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 '엄청난 유연성'을 선물한다. 다음 코드를 보자.
class Company {
public static Person getMember(String name) {
if ("Employer".equals(name))
return new Employer(name);
else
return new Employee(name);
}
}
class Employee extends Person { }
class Employer extends Person { }(굉장히 부실한 코드지만 알기쉽게 위해 일부러 그런거니 그냥 넘어가도록 하자..)
위 코드에서는 name 에 따라서 Employee 를 리턴할 지, Employer 를 리턴할 지를 결정하고 있다. OOP의 SOLID 원칙을 잘 고수하여 개발하였다면, SOLID의 L (리스코프 치환 법칙)에 의거, getMember 의 구현이 변경되더라도, 이 메서드를 사용하는 클라이언트 입장에서는 그걸 모른 채 계속 사용할 수 있다.
장점 4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
장점 3에서도 언급한 것 처럼, 매개 변수 name 에 따라서 Person 클래스의 하위 객체인 Employee 혹은 Employer 를 리턴할 지 결정할 수 있다. 이 코드를 사용하는 클라이언트 입장에서는 이 객체가 어느 클래스의 인스턴스인지 알 수도 없고, 알 필요도 없다.
장점 5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
이런 유연함은 서비스 제공자 프레임워크(Service Provider Framework)를 만드는 근간이 된다. 대표적인 서비스 제공자 프레임워크로는 JDBC가 있겠다.
서비스 제공자 프레임워크는 3개의 핵심 컴포넌트(와 추가 1개의 컴포넌트)로 이루어진다.
- 서비스 인터페이스 (Service Interface)
- 구현체의 동작을 정의
- JDBC 에서는 Connection
- 제공자 등록 API (Provider Registration API)
- 제공자가 구현체를 등록
- JDBC에서는 DriverManager.registerDriver
- 서비스 접근 API (Service Access API)
- 클라이언트가 서비스의 인스턴스를 얻을 떄 사용
- JDBC에서는 DriverManager.getConnection
- 서비스 제공자 인터페이스 (부가) (Service Provider Interface)
- 서비스 인터페이스의 팩토리 객체를 설명
- JDBC에서는 Driver
(개인적으로 장점 5는 아직 잘 안 와닿는 느낌이다.)
이제 단점을 알아보도록 하자.
단점 1. 생성자를 만들지 않고 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
어떤 클래스를 상속받아 하위 클래스를 만들기 위해서라면, public 혹은 protected 수준의 생성자를 만들어야 한다. 그런데 이런 생성자를 제공하지 않거나, private 생성자만 선언되어 있을 경우 하위 클래스를 만들 수 없다. 만약 상속보다 컴포지션 사용을 강요하거나, 불변 타입으로 만드려면 이는 오히려 장점으로 다가올 수도 있다.
단점 2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
생성자처럼 API 설명에 명확하게 드러나지 않으며, 사용자는 이를 인스턴스화할 방법을 알아내야 한다. 프로그래머는 정적 팩토리 메서드를 API 문서에 잘 써놓던지, 메서드 이름도 널리 알려진 규약을 따라 짓는 식으로 문제를 완화해야 한다.
자주 사용하는 명명법
| 메서드명 | 설명 | 예제 |
|---|---|---|
| from | 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 | Date d = Date.from(instant); // instant 는 long이 될 수도, string이 될 수도 있다. |
| of | 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 Set<Rank> faceCards - EnumSet.of(JACK, QUEEN, KING); | |
| valueOf | from과 of의 더 자세한 버전 | BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);// Integger.MAX_VALUE 라는 정적 값을 명시 |
| instance, getInstance | 매개변수가 있을 경우, 명시된 인스턴스를 반환, 같은 인스턴스임을 보장하지는 않는다. | StackWalker luke = StackWalker.getInstance(options); |
| create, newInstance | 매번 새로운 인스턴스를 생성해 반환한다. | 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<Complaint> litany = Collections.list(legacyLitany); |
정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는게 좋다. 보통은 정적 팩터리 메서드가 더 좋은 점이 많으므로, 무분별한 public 생성자를 사용하는 대신 정적 팩터리 메서드를 사용하는 쪽으로 습관을 고쳐보자.
References : 이펙티브 자바 3/E 8-13p
잘 읽었습니다 :p