구성 설정 문제에 어떤 디자인 패턴을 적용 할 수 있습니까?

크고 복잡한 소프트웨어 제품에서 구성 가능한 설정을 관리하는 것은 큰 고통이됩니다. 문제에 대한 두 가지 접근 방식은 다음과 같습니다.

• 시스템의 각 구성 요소가 구성 파일 또는 레지스트리 설정에서 자체 구성을로드하도록합니다.
• 모든 구성 가능한 시스템 설정을로드하고 각 구성 요소가 설정에 대해 설정 로더를 쿼리하도록하는 설정 로더 클래스가 있습니다.

이러한 접근 방식은 모두 나에게 잘못되었다고 느낍니다.

문제를 단순화하는 데 사용할 수있는 디자인 패턴이 있습니까? 아마도 의존성 주입 기술을 활용할 수있을 것입니다.

쿼리 설정,로드 및 저장을위한 인터페이스를 만드는 것을 선호합니다. 의존성 주입을 사용하여이를 필요한 각 구성 요소에 주입 할 수 있습니다.

이를 통해 구성 전략을 대체 할 수있는 유연성을 제공하고 모든 작업을 수행 할 수있는 공통 기반을 제공합니다. 저는 단일 전역 "설정 로더"(옵션 2)보다이 옵션을 선호합니다. 특히 필요한 경우 단일 구성 요소에 대한 구성 메커니즘을 재정의 할 수 있기 때문입니다.

저는 현재 구성 키의 맵을 값에 유지하는 하나의 글로벌 싱글 톤 개체에 의해 구성이 관리되는 시스템에서 작업합니다. 일반적으로 시스템에서 동시성 병목 현상을 일으킬 수 있고 단위 테스트 등을 위해 조잡하기 때문에 이런 방식으로 수행되지 않았 으면합니다.

나는 Reed Copsey가 그것에 대한 권리를 가지고 있다고 생각합니다.

http://martinfowler.com/articles/injection.html

약간의 추가 사항도 있습니다 ... 모의 객체 유형 단위 테스트를 수행하려면 종속성 주입이 확실히 갈 길입니다.

이건 어때. 단일 메소드 configure (configuration)로 구성 가능한 인터페이스를 정의합니다. 구성 인수는 구성 매개 변수의 이름을 해당 값과 연관시키는 단순히 해시 테이블입니다.

루트 개체는 원하는 방식으로 구성 해시 테이블을 만들 수 있습니다 (예 : 구성 파일에서 읽기). 이 해시 테이블에는 루트 개체 iselft에 대한 구성 매개 변수와 해당 구성 요소, 하위 구성 요소, 하위 구성 요소 중 하나가 사용할 수있는 모든 매개 변수가 포함될 수 있습니다.

그런 다음 루트 개체는 구성 가능한 모든 구성 요소에서 configure (구성)를 호출합니다.

구성 로더를 정의하는 인터페이스의 여러 구현을 만들 수 있습니다. 기본적으로 하나의 기본 인터페이스를 configLoader로 정의한 다음 FileSystemLoader, ClasspathLoader, EnvVariablesLoader 등과 같은 다른 구현을 정의 할 수있는 전략 패턴입니다.이 링크의 세부 정보