생성자 대신 정적 팩토리 메서드

1. 생성자 대신 정적 팩토리 메서드를 사용할 수 없는지 생각해보자

 

일반적으로 클래스를 통해 객체를 만드는 것은 public으로 선언된 생성자(Constructor)로 이뤄진다.

하지만 이외에도 방법이 하나 더 있는데, 바로 public으로 선언된 정적 팩토리 메소드(static factory method)를 사용하는 것.

 

<장점>

1. 이름이 있다.

- 생성자 메서드의 이름은 클래스 이름으로 고정되기 때문에 이름 그 자체로 의미를 주기 어렵고, 생성자에 전달되는 파라미터만으로는 어떤 객체가 생성되는지를 설명할 수 없다.

- 정적 팩토리 메서드는 이름만 잘 지으면 사용하기도 쉽고 코드의 가독성도 좋아진다.

- 같은 시그니처(signature)를 갖는 생성자를 여러개 정의할 필요가 있을 때는 생성자를 사용하기보다는 정적 팩토리 메서드를 이용해 메서드 이름만으로 차이가 드러나도록 해주자..(???)

 

위와 같은 경우?

 

* 메서드 시그니처: 메서드의 선언부에 명시되는 파라미터의 리스트.

- 두 메서드의 파라미터의 개수와 타입, 순서가 같은 경우에 두 메서드의 시그니처가 같다고 말한다.

 

* 메서드 오버로딩(Overloading): 같은 이름의 메서드를 중복해서 정의하는 것.

- 하나의 이름으로 다양한 시그니처를 갖는 메서드들을 만들 수 있다.

 

 

# 정적 팩토리 메소드의 명명 규칙 =======

valueOf: 파라미터로 주어진 값과 같은 값을 갖는 객체를 반환한다 (형변환 역할)

of: valueOf의 축약 (주로 여러 개의 매개변수를 받아서 객체 생성)

from: 하나의 매개변수를 받아서 객체를 생성하는 경우

 

getInstance: 파라미터에 기술된 객체를 반환하고, 대개 싱글톤 객체를 받아올 때 사용.

* 항상 동일한 객체 반환을 보장하지는 않음!! 

* 싱글톤 패턴을 사용할 경우 파라미터 필요 없이 항상 같은 객체를 반환한다

 

newInstance: 호출할 때마다 다른 객체를 반환한다

=================================

 

2. 호출할 때마다 새로운 객체를 생성할 필요가 없다.

이미 만들어진 객체를 활용할 수도 있고, 만든 객체를 캐시해놓고 불필요한 재생성 및 낭비를 방지할 수도 있다.

- 객체를 반복해서 반환할 수 있으므로 어떤 시점에 어떤 객체가 얼마나 존재할 지를 통제할 수 있다.

=> "개체 통제 클래스"

 

싱글톤 패턴을 따르도록 할 수 있고, 객체 생성이 불가능한 클래스를 만들 수 있고, 변경이 불가능한 클래스의 경우 두 개의 같은 객체가 존재하지 못하도록 할 수 있다.

--> '==' 인 경우에만 a.equals(b)가 성립하게 된다. -> '==' 연산자를 사용해 비교하므로 성능 향상

(Enum이 '==' 비교가 가능한 이유이다.)

 

 

3. 자료형의 하위 자료형 객체를 반환할 수 있다.

- public으로 선언되지 않은 클래스의 객체를 반환해줄 수 있다.

- public 정적 팩토리 메서드가 반환하는 객체의 클래스가 public일 필요가 없다.

-> 구현 세부사항을 감출 수 있다. 캡슐화!

-> 인터페이스의 다형성을 적극 활용할 수 있다.

 

 

(+) DTO --> Entity 변환 시 꽤 유용하게 사용된다

- DTO 내에 public static toEntity() 메소드를 이용해 Entity를 반환해주도록 하는 메서드를 만들어두면 아주 편리하게 사용할 수 있음. 

 

(+) 단일 책임 원칙(SRP)에 따라 생성자는 오로지 객체를 생성하는 역할만 수행하도록 해줄 수 있다.

- 생성자는 객체의 생성이라는 단일 책임에만 집중하고, 정적 팩토리 메소드가 부가기능 추가 or 초기화 역할을 분담함으로써 단일책임 원칙을 지키도록 할 수 있다.

-> 단순히 객체 생성을 대신하는 것 뿐만 아니라, 객체지향적으로 프로그래밍 할 수 있도록 도움을 준다

 

 

<단점>

1. 생성자가 없으므로 하위 클래스를 만들 수가 없다. (상속 불가) -- 재사용성이 떨어짐

2. 메서드가 다른 정적 메서드와 확연히 구분되지가 않는다. 네이밍 컨벤션에 따라 작성되어야 함.