생성자를 사용할 때와 getInstance () 메서드 (정적 팩토리 메서드)를 사용할 때

생성자를 사용할 때와 getInstance () 메서드 (정적 팩토리 메서드)를 사용할 때

---

1. 생성자를 사용하는시기와 방법

   Foo bar = new Foo();
   

2. 그리고 언제 어떻게 getInstance () (정적 팩토리 메서드)를 사용해야합니까?

   Foo bar = Foo.getInstance();
   

이 둘의 차이점은 무엇입니까, 나는 항상 첫 번째 방법을 사용하지만 언제 두 번째 방법을 사용해야합니까?

---

나는 질문이 실제로 생성자 대 정적 팩토리 메소드에 관한 것이라고 생각하는 동안 모든 사람들이 싱글 톤에 초점을 맞추는 것 같습니다 .

이것은 실제로 항목 1 : Joshua Bloch 의 Effective Java 생성자 대신 정적 팩토리 메소드를 고려하십시오 .

항목 1 : 생성자 대신 정적 팩토리 메서드 고려

클래스가 클라이언트가 자신의 인스턴스를 얻을 수 있도록 허용하는 일반적인 방법은 공용 생성자를 제공하는 것입니다. 모든 프로그래머의 툴킷에 포함되어야하는 또 다른 기술이 있습니다. 클래스는 클래스 의 인스턴스를 반환하는 정적 메서드 인 공용 정적 팩토리 메서드를 제공 할 수 있습니다 . 다음은 Boolean(기본 유형에 대한 박스형 기본 클래스) 의 간단한 예입니다 boolean. 이 메소드는 부울 프리미티브 값을 Boolean객체 참조 로 변환합니다 .

public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE;
}

정적 팩토리 방법은 디자인 패턴 의 팩토리 방법 패턴 과 동일하지 않습니다 [Gamma95, p. 107]. 이 항목에 설명 된 정적 팩토리 방법은 디자인 패턴 에서 직접적으로 동일하지 않습니다 .

클래스는 클라이언트에게 생성자 대신 또는 생성자에 추가하여 정적 팩토리 메서드를 제공 할 수 있습니다. 공용 생성자 대신 정적 팩토리 메서드를 제공하면 장점과 단점이 모두 있습니다.

장점 (책 인용) :

• 정적 팩토리 메서드의 한 가지 장점은 생성자와 달리 이름이 있다는 것입니다.
• 정적 팩토리 메서드의 두 번째 장점은 생성자와 달리 호출 될 때마다 새 개체를 만들 필요가 없다는 것입니다.
• 정적 팩토리 메서드의 세 번째 장점은 생성자와 달리 반환 유형의 모든 하위 유형의 객체를 반환 할 수 있다는 것입니다.
• 정적 팩토리 메서드의 네 번째 장점은 매개 변수가있는 형식 인스턴스를 만드는 자세한 정도를 줄이는 것입니다.

단점 (여전히 책 인용) :

• 정적 팩토리 메서드 만 제공 할 때의 가장 큰 단점은 공용 또는 보호 된 생성자가없는 클래스는 하위 클래스화할 수 없다는 것입니다.
• 정적 팩토리 메소드의 두 번째 단점은 다른 정적 메소드와 쉽게 구별 할 수 없다는 것입니다.

---

때 내가해야 : 당신은 두 가지 질문이있어 전화getInstance() 방법을, 나는 때를해야 생성 을?

당신이 전화를 할 것인지 여부를 결정하는 경우getInstance() 방법은 간단합니다. 언제 호출해야하는지 알아 보려면 클래스 문서를 읽어야합니다. 예를 들면, NumberFormat생성자 제공 하고getInstance() 방법; 이 getInstance()방법은 현지화 된 NumberFormat. 를 들어 Calendar, 다른 한편으로는, 생성자가 보호됩니다. 당신 이 전화 getInstance()를받을 수 있습니다.

생성 여부를 결정하는 경우getInstance() 방법을, 당신은 당신이 달성하기 위해 노력하고 무엇을 결정해야합니다. 어느 쪽이든 당신은 하지 않는 사람들이 생성자를 (당신이 만드는 전화 할 싱글 또는 공장 ), 또는 (같이 괜찮다 NumberFormat가 발신자의 편의를 위해 일부 개체를 초기화하는 경우, 위).

---

짧은 이야기? getInstance()자신의 코드에서 메서드를 만드는 것에 대해 걱정하지 마십시오 . 유용 할 때가되면 알게 될 것입니다. 그리고 일반적으로 클래스의 생성자를 호출 할 수 있다면 클래스가 getInstance()메서드를 제공하더라도 그렇게해야 할 것 입니다.

---

getInstance 메소드의 용도 :

• 시공을 제어 / 제한하려는 경우 (예 : Singleton)
• Factory 패턴 구현 (예 : DriverManager.getConnection)
• 인스턴스 생성 방법에 대해 더 나은 이름을 제공하려면 (생성자는 클래스 이름과 동일한 이름을 가져야 함) NumberFormat 팩토리 메서드 getCurrencyInstance , getIntegerInstance 및 기타를 이에 대한 예로 확인하십시오.

그러나 대부분의 경우 객체는 단순한 POJO 이며 공용 생성자를 사용하는 것이 가장 실용적이고 확실한 솔루션입니다.

U1 : 다른 클래스의 getInstance

다른 클래스의 인스턴스를 반환하려면 :

public class FooFactory {
    public static Foo getInstance() {
        return new Foo();
    }
}

NumberFormat.getInstance메서드는 실제로 DecimalFormat.

U2 : 싱글 톤 문제

싱글 톤 패턴은 객체 지향 프로그래밍의 많은 이점을 제한합니다. 싱글 톤에는 일반적으로 개인 생성자가 있으므로 확장 할 수 없습니다. getInstance 메소드를 통해 액세스하고 인터페이스를 참조하지 않으므로 다른 구현을 위해 스왑 할 수 없습니다.

---

둘 다 사용할 수 있다면 제대로 구현되지 않은 싱글 톤 패턴 처럼 들립니다 .

시스템에 클래스의 단일 인스턴스 만 있고 생성자를 비공개로 만들려는 경우 두 번째 옵션을 사용합니다.

첫 번째를 사용하여 클래스의 여러 개체를 만들 수 있습니다.

그러나 수업에 두 가지 가능성을 모두주지 마십시오.

Take care not to over-use singletons, only use them if really only one instance shall exist in the system otherwise you would limit the possibilities of re-use of your class in other projects. It sounds interesting to be able to call getInstance from everywhere in your project but that makes unclear who actually owns that instance: nobody and/or all. If you have a lot of singletons in a project you can bet that the system is poorly designed (usually). Singletons should be used with care, the same advice than for global variables apply.

---

One case in which I always prefer a static factory over a regular constructor is when I know the object construction will be slowish. I do simple initialization on constructor, but if I need to create something heavy I'll use a static method and document the behavior.

---

Singletons are evil. The problems I've seen surrounding it are not about re-use or extendability of a system (although I could see how that could occur), more so that I can't count the number of times i've seen obscure bugs in a system that arise from singletons.

If you do need to use a singleton, ensure it's scope is extremely narrow, i.e. judiciously limit the number of other objects in your system that know about it.

참고URL : https://stackoverflow.com/questions/3169372/when-to-use-a-constructor-and-when-to-use-getinstance-method-static-factory-m