편집 : 이 질문은 이론적 문제를 설명하고 싶습니다. 필수 매개 변수에 생성자 인수를 사용하거나 API가 잘못 사용되면 런타임 예외가 발생할 수 있음을 알고 있습니다. 그러나 생성자 인수 또는 런타임 검사가 필요 없는 솔루션을 찾고 있습니다.

다음 Car과 같은 인터페이스 가 있다고 상상해보십시오 .

public interface Car {
    public Engine getEngine(); // required
    public Transmission getTransmission(); // required
    public Stereo getStereo(); // optional
}

의견이 제안 같이,이 Car이 있어야 Engine하고 Transmission있지만은 Stereo선택 사항입니다. 즉 build(), Car인스턴스를 가질 수있는 빌더 는 build()메소드 Engine와 Transmission둘 다 이미 빌더 인스턴스에 제공된 경우 에만 메소드 를 가져야합니다. 이렇게하면 형식 검사기가 또는 Car없이 인스턴스 를 만들려고 시도하는 코드를 컴파일하지 않습니다 .EngineTransmission

이것은 단계 빌더를 요구 합니다. 일반적으로 다음과 같은 것을 구현합니다.

public interface Car {
    public Engine getEngine(); // required
    public Transmission getTransmission(); // required
    public Stereo getStereo(); // optional

    public class Builder {
        public BuilderWithEngine engine(Engine engine) {
            return new BuilderWithEngine(engine);
        }
    }

    public class BuilderWithEngine {
        private Engine engine;
        private BuilderWithEngine(Engine engine) {
            this.engine = engine;
        }
        public BuilderWithEngine engine(Engine engine) {
            this.engine = engine;
            return this;
        }
        public CompleteBuilder transmission(Transmission transmission) {
            return new CompleteBuilder(engine, transmission);
        }
    }

    public class CompleteBuilder {
        private Engine engine;
        private Transmission transmission;
        private Stereo stereo = null;
        private CompleteBuilder(Engine engine, Transmission transmission) {
            this.engine = engine;
            this.transmission = transmission;
        }
        public CompleteBuilder engine(Engine engine) {
            this.engine = engine;
            return this;
        }
        public CompleteBuilder transmission(Transmission transmission) {
            this.transmission = transmission;
            return this;
        }
        public CompleteBuilder stereo(Stereo stereo) {
            this.stereo = stereo;
            return this;
        }
        public Car build() {
            return new Car() {
                @Override
                public Engine getEngine() {
                    return engine;
                }
                @Override
                public Transmission getTransmission() {
                    return transmission;
                }
                @Override
                public Stereo getStereo() {
                    return stereo;
                }
            };
        }
    }
}

다른 빌더 클래스 ( Builder,, ) 체인이 있으며 BuilderWithEngine, CompleteBuilder필요한 세터 메소드를 하나씩 추가하고 마지막 클래스에는 모든 선택적 세터 메소드가 포함됩니다.
이것은이 단계 작성기의 사용자가 작성자가 필수 세터를 사용할 수있는 순서로 제한되어 있음을 의미합니다 . 다음은 가능한 사용법의 예입니다 ( engine(e)처음에는 순서대로 , 그 뒤에는 transmission(t)선택 사항 임 stereo(s)).

new Builder().engine(e).transmission(t).build();
new Builder().engine(e).transmission(t).stereo(s).build();
new Builder().engine(e).engine(e).transmission(t).stereo(s).build();
new Builder().engine(e).transmission(t).engine(e).stereo(s).build();
new Builder().engine(e).transmission(t).stereo(s).engine(e).build();
new Builder().engine(e).transmission(t).transmission(t).stereo(s).build();
new Builder().engine(e).transmission(t).stereo(s).transmission(t).build();
new Builder().engine(e).transmission(t).stereo(s).stereo(s).build();

그러나 특히 빌더에 세터뿐만 아니라 가산기가 있거나 사용자가 빌더의 특정 특성을 사용할 수있는 순서를 제어 할 수없는 경우, 이는 빌더 사용자에게 이상적이지 않은 시나리오가 많이 있습니다.

내가 생각할 수있는 유일한 해결책은 매우 복잡합니다. 필수 속성의 모든 조합이 설정되었거나 아직 설정되지 않은 경우, 나는 다른 필수 강제 세터를 호출하기 전에 호출 해야하는 것을 알고있는 전용 빌더 클래스를 만들었습니다. build()메소드가 사용 가능해야하는 상태 및 해당 세터 각각이 build()메소드 를 포함하는 한 단계에 가까운 더 완전한 유형의 빌더를 리턴합니다 .
나는 아래의 코드를 추가,하지만 당신은 내가 당신이를 만들 수있는 FSM 만들 유형의 시스템을 사용하고 있다고 말할 수 Builder중 하나로 전환 할 수있다, BuilderWithEngine또는 BuilderWithTransmission둘 다 다음으로 전환 될 수있는 CompleteBuilder, 어떤 구현build()방법. 이러한 빌더 인스턴스에서 선택적 세터를 호출 할 수 있습니다.

public interface Car {
    public Engine getEngine(); // required
    public Transmission getTransmission(); // required
    public Stereo getStereo(); // optional

    public class Builder extends OptionalBuilder {
        public BuilderWithEngine engine(Engine engine) {
            return new BuilderWithEngine(engine, stereo);
        }
        public BuilderWithTransmission transmission(Transmission transmission) {
            return new BuilderWithTransmission(transmission, stereo);
        }
        @Override
        public Builder stereo(Stereo stereo) {
            super.stereo(stereo);
            return this;
        }
    }

    public class OptionalBuilder {
        protected Stereo stereo = null;
        private OptionalBuilder() {}
        public OptionalBuilder stereo(Stereo stereo) {
            this.stereo = stereo;
            return this;
        }
    }

    public class BuilderWithEngine extends OptionalBuilder {
        private Engine engine;
        private BuilderWithEngine(Engine engine, Stereo stereo) {
            this.engine = engine;
            this.stereo = stereo;
        }
        public CompleteBuilder transmission(Transmission transmission) {
            return new CompleteBuilder(engine, transmission, stereo);
        }
        public BuilderWithEngine engine(Engine engine) {
            this.engine = engine;
            return this;
        }
        @Override
        public BuilderWithEngine stereo(Stereo stereo) {
            super.stereo(stereo);
            return this;
        }
    }

    public class BuilderWithTransmission extends OptionalBuilder {
        private Transmission transmission;
        private BuilderWithTransmission(Transmission transmission, Stereo stereo) {
            this.transmission = transmission;
            this.stereo = stereo;
        }
        public CompleteBuilder engine(Engine engine) {
            return new CompleteBuilder(engine, transmission, stereo);
        }
        public BuilderWithTransmission transmission(Transmission transmission) {
            this.transmission = transmission;
            return this;
        }
        @Override
        public BuilderWithTransmission stereo(Stereo stereo) {
            super.stereo(stereo);
            return this;
        }
    }

    public class CompleteBuilder extends OptionalBuilder {
        private Engine engine;
        private Transmission transmission;
        private CompleteBuilder(Engine engine, Transmission transmission, Stereo stereo) {
            this.engine = engine;
            this.transmission = transmission;
            this.stereo = stereo;
        }
        public CompleteBuilder engine(Engine engine) {
            this.engine = engine;
            return this;
        }
        public CompleteBuilder transmission(Transmission transmission) {
            this.transmission = transmission;
            return this;
        }
        @Override
        public CompleteBuilder stereo(Stereo stereo) {
            super.stereo(stereo);
            return this;
        }
        public Car build() {
            return new Car() {
                @Override
                public Engine getEngine() {
                    return engine;
                }
                @Override
                public Transmission getTransmission() {
                    return transmission;
                }
                @Override
                public Stereo getStereo() {
                    return stereo;
                }
            };
        }
    }
}

당신이 알 수 있듯이,이 것이 필요한 다른 빌더 클래스의 수로서, 확장 성이 좋지 않습니다 O (2 ^ n은) 여기서 n은 필수 세터의 수입니다.

따라서 내 질문 : 이보다 우아하게 수행 할 수 있습니까?

(Scala도 수용 가능하지만 Java와 작동하는 답변을 찾고 있습니다)

제공 한 메서드 호출에 따라 두 가지 요구 사항이있는 것 같습니다.

1. 하나의 (필수) 엔진, 하나의 (필수) 전송 및 하나의 (선택적) 스테레오 만.
2. 하나 이상의 (필수) 엔진, 하나 이상의 (필수) 변속기 및 하나 이상의 (선택적) 스테레오.

여기에서 첫 번째 문제 는 수업 이 무엇을 원하는지 모른다 는 것입니다. 그 중 일부는 빌드 된 객체의 모양을 알 수 없다는 것입니다.

자동차는 엔진 하나와 변속기 하나만 가질 수 있습니다. 하이브리드 자동차조차 엔진이 하나만 있습니다 (아마도 GasAndElectricEngine)

두 가지 구현을 모두 다룰 것입니다.

public class CarBuilder {

    public CarBuilder(Engine engine, Transmission transmission) {
        // ...
    }

    public CarBuilder setStereo(Stereo stereo) {
        // ...
        return this;
    }
}

과

public class CarBuilder {

    public CarBuilder(List<Engine> engines, List<Transmission> transmission) {
        // ...
    }

    public CarBuilder addStereo(Stereo stereo) {
        // ...
        return this;
    }
}

엔진과 변속기가 필요한 경우 생성자에 있어야합니다.

어떤 엔진이나 변속기가 필요한지 모르면 아직 설정하지 마십시오. 스택을 너무 멀리 빌더를 작성하고 있다는 표시입니다.

null 객체 패턴을 사용하지 않는 이유는 무엇입니까? 이 빌더를 제거하십시오. 작성할 수있는 가장 우아한 코드는 실제로 작성할 필요가없는 코드입니다.

public final class CarImpl implements Car {
    private final Engine engine;
    private final Transmission transmission;
    private final Stereo stereo;

    public CarImpl(Engine engine, Transmission transmission) {
        this(engine, transmission, new DefaultStereo());
    }

    public CarImpl(Engine engine, Transmission transmission, Stereo stereo) {
        this.engine = engine;
        this.transmission = transmission;
        this.stereo = stereo;
    }

    //...

}

첫째, 내가 일했던 상점보다 시간이 더 많지 않다면, 어떤 작업 순서를 허용하거나 하나 이상의 라디오를 지정할 수 있다는 사실에 따라 살 가치가 없을 것입니다. 사용자 입력이 아닌 코드에 대해 이야기하고 있으므로 컴파일 시간에 1 초가 아닌 단위 테스트 중에 실패 할 수있는 어설 션이있을 수 있습니다.

그러나 주석에 주어진 바와 같이 엔진과 변속기가 있어야한다는 제약 조건이있는 경우 빌더의 생성자 인 모든 필수 속성을 배치하여이를 강제하십시오.

new Builder(e, t).build();                      // ok
new Builder(e, t).stereo(s).build();            // ok
new Builder(e, t).stereo(s).stereo(s).build();  // exception on second call to stereo as stereo is already set 

선택적인 스테레오 일 뿐이라면, 빌더의 서브 클래스를 사용하여 최종 단계를 수행하는 것이 가능하지만, 그보다 더 많은 것은 테스트가 아닌 컴파일 타임에 오류를 얻는 것의 노력이 가치가 없을 것입니다.

필요한 다른 빌더 클래스 수는 O (2 ^ n)입니다. 여기서 n은 필수 설정자 수입니다.

이 질문에 대한 올바른 방향을 이미 추측했습니다.

컴파일 타임 검사를 받으려면 (2^n)유형 이 필요 합니다. 런타임 검사를 받으려면 (2^n)상태 를 저장할 수있는 변수가 필요합니다 . n비트 정수 할 것입니다.

C ++ 지원하므로 비 템플릿 유형 파라미터 (예를 들어, 정수 값) 은 C ++ 클래스 템플릿으로 인스턴스화하는 것이 가능하다 O(2^n)유사한 방식을 사용하여 다른 유형 이 .

그러나 유형이 아닌 템플릿 매개 변수를 지원하지 않는 언어에서는 유형 시스템을 사용하여 O(2^n)다른 유형 을 인스턴스화 할 수 없습니다 .

다음 기회는 Java 어노테이션 (및 C # 속성)입니다. 이러한 추가 메타 데이터는 주석 프로세서 가 사용될 때 컴파일 타임에 사용자 정의 동작을 트리거하는 데 사용될 수 있습니다 . 그러나 구현하기에는 너무 많은 작업이 필요합니다. 이 기능을 제공하는 프레임 워크를 사용하는 경우이를 사용하십시오. 그렇지 않으면 다음 기회를 확인하십시오.

마지막으로 O(2^n)다른 상태를 런타임에 변수 (문자 적으로 최소 n비트 너비 를 갖는 정수 )로 저장하는 것이 매우 쉽습니다. 이것이 가장 이득이 높은 답변이 런타임시이 검사를 수행하도록 권장하는 이유입니다. 잠재적 이득과 비교할 때 컴파일 타임 검사를 구현하는 데 너무 많은 노력이 필요하기 때문입니다.