구성 클래스 / 구조 : 패턴 또는 안티 패턴? 대안?

프로그램에 새로운 구성 옵션을 추가하면, 옵션을 수행해야하는 위치에서 여러 가지 파급 효과가 발생할 수 있습니다. 내가 알고있는 이것을 처리하는 세 가지 기본 방법이 있습니다.

1. 기본적으로 명시 적으로 필요한 모든 구성 설정을 프로그램의 일부로 전달하십시오. 이것은 가장 명백한 방법이며 가장 많이 분리하는 방법입니다. 단점은 이것이 장황하고 부서지기 쉽다는 것입니다.

2. 가장 자주 사용되는 구성 설정을 전역 / 정적으로 설정하십시오. 이것은 가장 간단한 방법이지만 원거리에서 조치를 취하고 테스트 가능성을 방해하며 구성이 실제로 전역 적이라고 가정합니다 (언제든지 한 번에 하나의 구성 만 원함).

3. 전체 프로그램 또는 프로그램 내 각 주요 관심사에 대한 모든 구성 옵션이 포함 된 구성 클래스 / 구조를 만든 다음 명시 적으로 전달하십시오. 이것은 (1)보다 덜 분명하지만 (2)보다 더 분명합니다. 하나의 함수 호출에 대해서만 설정을 변경하려는 경우 구성 오브젝트를 복제하고이 하나의 값을 변경할 수 있습니다. 이것은 테스트와 실제 모두에 유용합니다. 그러나 여전히 많은 양의 정보가 필요하지 않은 함수에 전달 될 수 있으며 구성 클래스 / 구조체의 값을 변경하면 여전히 먼 거리에서 동작이 발생할 수 있습니다.

(3) 패턴 또는 반 패턴을 고려 하시겠습니까? 안티 패턴이라면 대신 무엇을합니까?

최고의 솔루션은 여러 구성 인터페이스를하고 당신이 원하는대로이를 구현하는 것입니다. 이것은 접근성을 제한하고 지역화 된 것들을 유지합니다. 그러나 단순히 단일 클래스의 모든 구성을 척킹하고 더 많은 중력 문제에 대한 문제로 넘어가는 것보다 훨씬 많은 노력이 필요합니다. 이것은 UtterlyCrucialAlwaysChangingClass가 아닌 구성입니다. 거의 동일하게 유지됩니다. 모든 것을 글로벌하게 만들지 않고 구현이 일관된 한 걱정하지 않아도됩니다.

디커플링을 통해보다 쉽게 ​​테스트 할 수 있고 오브젝트가 의존하는 구성 설정이 명시 적으로 작성되므로 옵션 1을 선호합니다. 객체에 구성 설정이 필요한 경우 생성자 인수 또는 setter 메서드를 사용하여 객체에 명시 적으로 제공합니다. 종속성 주입 프레임 워크를 사용하여 해당 구성 설정을 오브젝트에 주입하여 자세한 정보를 줄이십시오.

구성 파일이 XML로 작성된 경우를 상상해보십시오. 그런 다음이 XML 조각을 각 구성 요소에 전달하면 구성 데이터를 얻을 수 있습니다.

.NET을 사용하는 경우 XmlSerialiser를 사용하여 구성 Xml에서 개체 계층을 만들고이 개체를 구성으로 전달할 수있는 DataContracts를 사용하여 클래스를 만들 수 있습니다.

그런 다음 다음 문제를 소개합니다. 구성 데이터에는 세 가지 부분이 있습니다. 이 특정 제품으로 작동하도록 코드 라이브러리를 구성하는 구조적 애플리케이션 구성입니다. 시스템의 각 사용자마다 다른 설치 특정 설정 및 사용자 기본 설정 / 설정 데이터가 포함 된 사이트 구성 설정.

어느 부분이 어느 부분인지 알고 이러한 데이터 설정을 별도로 유지하면 고객 설정을 잃지 않고 업데이트 설치가 훨씬 간단 해집니다.

옵션 # 3의 클래스를 정적으로 만들 것입니다. 그래서 대신

//create SomeCl
Foo f = new Foo();
f.setConfigInst(cfg);
...
...
//Inside Foo
public void setConfig(MyAppConfig c) { localCfg = c; }
...
//somewhere else:
x = localCfg.getConfigForX();

당신은 단지 가질 수 있습니다 :

//Inside Foo
x = MyAppConfig.getConfigForX();

구성 데이터로드 / 저장에 대한 세부 사항이 MyAppConfig클래스 내에서 발생하도록하십시오 . 물론 다른 목적에 따라 다른 클래스와 같이 더 복잡한 변형을 가질 수 있습니다.

이러한 접근 방식은 문제가 될 수있는 유일한 경우는 다른 구성의 여러 인스턴스에 대한 작업에 필요한 몇 가지 이유로 경우 것 같은 시간에 내가 그런 상황 건너 아직 있지만.

"3 계층 (인터페이스, 비즈니스 로직, 데이터 액세스)"접근 방식을 사용하는 프로젝트를 진행하고 있습니다. 응용 프로그램은 다중 사용자 웹 서버 또는 클라이언트 서버 일 수 있습니다.

우리는 사용자가 작업하는 동안 PC에 가장 적합한 3 가지 구성으로 작업합니다. 현재 사용자를위한 두 번째, 모든 사용자 및 클라이언트 앱을위한 세 번째 글로벌 구성.

각 구성은 응용 프로그램의 각 인스턴스에서 개체로 표시됩니다.

이 접근법은 프로젝트에 도움이 될 수 있습니다.