1) 생성자 대신 정적 팩토리 메서드를 고려하자

전통적인 public 생성자
```
String str = new String("java");
```

정적 팩토리 메서드(static factory method)

public static final Boolean TRUE  = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);

/**
 * 매개변수로 boolean을 받아 Boolean 객체 참조로 변환하여 반환
 * @param b a boolean value.
 * @return a Boolean instance representing b.
 */
public static Boolean valueOf(boolean b) {
	return (b ? TRUE : FALSE);
}

//Boolean b = Boolean.valueOf("java");

장점

이름을 가질 수 있다 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다. 그렇다고 매개변수들의 순서를 다르게 한 생성자를 새로 추가 할 수도 있지만 오히려 혼란을 가중 할 수도 있다. 반면 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. 이는 코드의 가독성과 생산성을 높여준다.
```
//1.생성자 방식, 중간 부분과 마지막 부분의 의미가 직관적이지 않다.
PhoneNumber phoneNumber = new PhoneNumber(010, 1234, 5678);

//2_1.정적 팩토리 메서드 방식
PhoneNumber phoneNumber = PhoneNumber.from("010", "1234", "5678");

//2_2.메서드 이름 구체화
PhoneNumber phoneNumber = PhoneNumber.fromMobile("010", "1234", "5678");
PhoneNumber officeNumber = PhoneNumber.fromOffice("02", "1234", "5678");
```

**호출될 때마다 인스턴스를 새로 생성하지 않아도 된다** 이 덕분에 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있어서 성능과 메모리 효율성을 높일 수 있다.

/*대표적인 예시: Boolean.valuof(boolean)*/

//생성자 방식(매번 새로운 객체 생성)
Boolean trueValue1 = new Boolean(true);  // 매번 새로운 인스턴스 생성
Boolean trueValue2 = new Boolean(true);  // 새로운 인스턴스 생성

//정적 팩토리 메서드 방식(객체 재사용)
Boolean trueValue1 = Boolean.valueOf(true);  // 미리 생성된 객체 반환
Boolean trueValue2 = Boolean.valueOf(true);  // 동일한 객체 반환

/*또 다른 예시: Integer.valueOf(int)*/
//-128~127까지의 작은 정수 값에 대해서는 새로운 객체를 생성하지 않고, 캐시된 객체를 반환.
Integer smallInt1 = Integer.valueOf(100);  // 캐시된 인스턴스 반환
Integer smallInt2 = Integer.valueOf(100);  // 동일한 인스턴스 반환

Integer largeInt1 = Integer.valueOf(1000);  // 새로운 인스턴스 생성
Integer largeInt2 = Integer.valueOf(1000);  // 또 다른 새로운 인스턴스 생성

플라이웨이트 패턴도 동일한 객체를 공유하는 패턴으로 정적 팩토리 메서드로 객체를 캐싱해, 중복된 객체 생성을 피하는 것이 플라이웨이트 패턴의 핵심이다. enum(열거 타입)은 싱글턴 패턴을 보장하는 대표적인 예로, 열거형 상수는 하나의 인스턴스만 생성되며 인스턴스가 하나만 만들어진다는 것이 보장된다. 이는 인스턴스 통제의 중요한 사례 중 하나로, 자바에서는 이를 통해 안정성과 일관성을 유지할 수 있다.

//인스턴스 통제 클래스
public enum SingletonEnum {
    INSTANCE;

    public void doSomething() {
        // ...
    }
}
//enum을 사용하면 인스턴스가 단 하나만 존재함을 보장하며,
//추가적인 생성이나 인스턴스화가 불가능하다.

반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다. 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 유연성을 제공한다. 인터페이스를 정적 펙터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크(java.util.Collections)를 만드는 핵심 기술이기도 하다.

public interface Coffee {
    String getDescription();
    
    static Coffee order(String type) {
        switch (type.toLowerCase()) {
            case "americano":
                return new Americano();
            case "latte":
                return new Latte();
            case "cappuccino":
                return new Cappuccino();
            default:
                throw new IllegalArgumentException("Unknown coffee type: " + type);
        }
    }
}

public class Americano implements Coffee {
    @Override
    public String getDescription() {
        return "아메리카노";
    }
}

public class Latte implements Coffee {
    @Override
    public String getDescription() {
        return "라떼";
    }
}

public class Cappuccino implements Coffee {
    @Override
    public String getDescription() {
        return "카푸치노";
    }
}

public class Cafe {
    public static void main(String[] args) {
        Coffee americano = Coffee.order("americano");
        Coffee latte = Coffee.order("latte");

        System.out.println(americano.getDescription());  // "아메리카노"
        System.out.println(latte.getDescription());      // "라떼"
    }
}

정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. 정적 팩토리 메서드는 메서드를 작성할 때 반환할 객체의 구체적인 클래스가 아직 구현되지 않았거나, 구현이 결정되지 않은 경우에도 메서드를 정의할 수 있는 유연함을 제공한다. 이는 서비스 제공자 프레임워크와 같은 구조를 설계하는 데 유용하다.

서비스 제공자 프레임워크의 핵심 컴포넌트

서비스 인터페이스: 서비스의 동작을 정의하는 인터페이스로, 클라이언트는 이 인터페이스를 통해 서비스에 접근한다.
제공자 등록 API: 제공자가 서비스 구현체를 등록할 때 사용하는 API로, 이 API를 통해 구현체를 시스템에 등록할 수 있다.
서비스 접근 API: 클라이언트가 서비스의 인스턴스를 얻을 때 사용하는 API로, 원하는 구현체의 조건을 명시할 수 있다.

클라이언트는 서비스 접근 API를 사용하여 원하는 구현체의 조건을 명시하거나, 조건을 명시하지 않으면 기본 구현체를 반환받을 수 있다. 이 과정에서 정적 팩토리 메서드가 반환할 객체의 구체적인 클래스가 이미 구현되지 않았더라도, 클라이언트는 인터페이스를 통해 서비스를 사용할 수 있다.

JDBC(Java Database Connectivity)는 정적 팩토리 메서드의 유연함을 잘 보여주는 사례이다. JDBC는 데이터베이스와 연결하기 위해 다음과 같은 핵심 컴포넌트를 사용한다.

서비스 인터페이스: Connection 인터페이스는 데이터베이스와의 연결을 정의한다.
제공자 등록 API: DriverManager.registerDriver() 메서드는 데이터베이스 드라이버를 등록한다.
서비스 접근 API: DriverManager.getConnection() 메서드는 데이터베이스에 연결하는 Connection 객체를 반환한다.

DriverManager.getConnection() 메서드는 등록된 드라이버 중 적절한 드라이버를 찾아 Connection 객체를 반환한다. 이때 드라이버 클래스는 애플리케이션 실행 시점에 동적으로 로드될 수 있다.

```java

public interface DatabaseConnection {
    void connect();
}

public class MySQLConnection implements DatabaseConnection {
    @Override
    public void connect() {
        System.out.println("MySQL 데이터베이스에 연결했습니다.");
    }
}

public class PostgreSQLConnection implements DatabaseConnection {
    @Override
    public void connect() {
        System.out.println("PostgreSQL 데이터베이스에 연결했습니다.");
    }
}

public class ConnectionFactory {
    public static DatabaseConnection createConnection(String type) {
        switch (type.toLowerCase()) {
            case "mysql":
                return new MySQLConnection();
            case "postgresql":
                return new PostgreSQLConnection();
            default:
                throw new IllegalArgumentException("지원하지 않는 데이터베이스 타입: " + type);
        }
    }
}
```

이 코드에서 `ConnectionFactory.createConnection(String type)` 메서드는 입력된 데이터베이스 타입에 따라 적절한 `DatabaseConnection` 구현체를 반환한다. `MySQLConnection`이나 `PostgreSQLConnection` 클래스는 실행 시점에 동적으로 로드되며, 클라이언트는 이들을 구체적으로 알 필요 없이 `DatabaseConnection` 인터페이스를 통해 작업할 수 있다.

단점

상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다. 어찌 보면 이 제약은 상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점으로 받아들일 수도 있다.

”컴포지션 vs 상속” 상속은 "is-a" 관계를 표현하는 데 적합하지만, 과도한 상속은 코드의 복잡성을 증가시키고, 유지보수를 어렵게 만들 수 있어. 반면, 컴포지션은 "has-a" 관계를 표현하여 객체를 조합하는 방식으로 기능을 확장하다.

```java
//상속 예시
public class Engine {
    // 엔진의 기능
}
public class Car extends Engine {
    // 자동차의 기능
}
```

이 경우 `Car`는 `Engine`의 모든 기능을 상속받게 되며, `Car` 객체는 `Engine`의 모든 메서드와 필드를 갖게 된다. 하지만 이는 자동차와 엔진 사이의 관계를 정확히 표현하지 못한다.

```java
//컴포지션 예시
public class Engine {
    // 엔진의 기능
}

public class Car {
    private Engine engine; // Car는 Engine을 가짐
    
    public Car(Engine engine) {
        this.engine = engine;
    }
    
    public void start() {
        // 엔진을 사용하여 자동차를 시작함
        engine.start();
    }
}
```

여기서 `Car` 클래스는 `Engine` 객체를 필드로 가지며, 엔진의 기능을 사용해 자동차를 조작한다. 이 방식은 자동차와 엔진의 관계를 명확히 표현하며, 다음과 같은 장점을 제공한다.
1. 유연성: 자동차는 다양한 종류의 엔진을 사용할 수 있다. `Car` 객체는 `Engine` 객체를 교체하여 다양한 엔진을 사용할 수 있다.
2. 확장성: 새로운 엔진 타입이 추가되더라도 `Car` 클래스는 수정할 필요 없이 새로운 엔진 클래스만 추가하면 된다.
3. 유지보수: `Car`와 `Engine`의 책임이 명확히 분리되어 있다. 각각의 클래스를 독립적으로 수정하거나 유지보수할 수 있다.

정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

따라서 API문서를 잘 작성하고, 메서드 이름을 잘 작성해주어야 한다.

명명 규칙

from: 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드 ex) Date d = Date.from(instant);
of: 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드 ex) Set<Rank> faceCards = EnumSet.of(JACK, QUEEN, KING);
valueOf: from과 of의 더 자세한 버전 ex) BigInteger prime = BigInteger.valueOf(Integer.MAX_VALUE);
instance 혹은 getInstance: (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지는 않는다. ex) StackWalker luke = StackWalker.getInstance(options)
create 혹은 newInstance: instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다. ex) Object newArray = Array.newInstance(classObject, arrayLen);