여러 스위치 케이스로 애플리케이션을 리팩터링하는 방법은 무엇입니까?

정수를 입력으로 사용하고 입력을 기반으로 다른 클래스의 정적 메소드를 호출하는 응용 프로그램이 있습니다. 새로운 숫자가 추가 될 때마다 다른 케이스를 추가하고 다른 클래스의 다른 정적 메소드를 호출해야합니다. 이제 스위치에 50 개의 케이스가 있으며, 다른 케이스를 추가해야 할 때마다 나는 소리 쳤다. 더 좋은 방법이 있습니까?

나는 몇 가지 생각을 하고이 아이디어를 생각해 냈습니다. 전략 패턴을 사용합니다. 스위치 케이스 대신 키가 입력 정수인 전략 오브젝트 맵이 있습니다. 메소드가 호출되면 오브젝트를 찾고 오브젝트의 일반 메소드를 호출합니다. 이렇게하면 스위치 케이스 구조를 사용하지 않아도됩니다.

어떻게 생각해?

이제 스위치에 50 개의 케이스가 있으며, 다른 케이스를 추가해야 할 때마다 나는 소리 쳤다.

나는 다형성을 좋아합니다. 나는 SOLID를 좋아합니다. 나는 순수한 객체 지향 프로그래밍을 좋아합니다. 나는 그들이 도덕적으로 적용되기 때문에 나쁜 담당자가 주어진 것을 싫어.

전략에 대한 리팩토링에 대한 좋은 사례는 없습니다. 리팩토링에는 이름이 있습니다. 이를 조건부로 다형성 대체 라고 합니다.

c2.com 에서 적절한 조언을 찾았습니다 .

동일하거나 매우 유사한 조건부 테스트가 자주 반복되는 경우에만 의미가 있습니다. 단순하고 거의 반복되지 않는 테스트의 경우 간단한 조건부를 여러 클래스 정의의 세부 정보로 대체하고 실제로 조건부 필요한 활동이 필요한 코드에서이 모든 것을 옮기면 코드 난독 화의 교과서 예제가 생성됩니다. 독단적 순도보다 명확성을 선호합니다. -댄 뮬러

50 개의 케이스가있는 스위치가 있으며 50 개의 오브젝트를 생성하는 대안이 있습니다. 오와 50 줄의 객체 구성 코드. 이것은 진행되지 않습니다. 왜 안돼? 이 리팩토링은 숫자를 50에서 줄이는 데 도움이되지 않습니다. 다른 곳에서 동일한 입력에 다른 switch 문을 작성해야하는 경우이 리팩토링을 사용하십시오. 이 리팩토링이 100으로 다시 50으로 바뀌기 때문에 도움이됩니다.

당신이 가진 유일한 스위치 인 것처럼 "스위치"를 언급하는 한, 나는 이것을 권장하지 않습니다. 리팩토링을 통해 얻을 수있는 유일한 장점은 일부 goofball이 50 개의 케이스 스위치를 복사하여 붙여 넣을 가능성이 줄어든다는 것입니다.

내가 추천하는 것은 제외 할 수있는 공통성에 대해이 50 가지 사례를 면밀히 검토하는 것입니다. 나는 50을 의미합니까? 정말? 많은 경우가 필요하십니까? 당신은 여기에 많은 것을하려고 할 것입니다.

코드의 일부 기능으로 초기화되는 전략 객체 맵만, 여기에는 여러 줄의 코드가 있습니다.

     myMap.Add(1,new Strategy1());
     myMap.Add(2,new Strategy2());
     myMap.Add(3,new Strategy3());

전략 개체는 모두 동일한 인터페이스를 구현해야하기 때문에 사용자와 동료가보다 균일 한 방식으로 별도의 클래스에서 호출되도록 함수 / 전략을 구현해야합니다. 이러한 코드는 종종보다 포괄적입니다.

     case 1:
          MyClass1.Doit1(someParameters);
          break;
     case 2:
          MyClass2.Doit2(someParameters);
          break;
     case 3:
          MyClass3.Doit3(someParameters);
          break;

그러나 새 번호를 추가해야 할 때마다이 코드 파일을 편집해야하는 부담에서 벗어나지 않습니다. 이 방법의 실제 이점은 다른 것입니다.

• 맵의 초기화는 이제 특정 숫자와 관련된 함수 를 실제로 호출 하는 디스패치 코드와 분리되며 후자는 더 이상 50 반복을 포함 하지 않습니다myMap[number].DoIt(someParameters) . 따라서이 디스패치 코드는 새로운 번호가 도착할 때마다 만질 필요가 없으며 공개 폐쇄 원칙에 따라 구현 될 수 있습니다. 또한 디스패치 코드 자체를 확장해야하는 요구 사항이있는 경우 더 이상 50 개의 장소를 변경할 필요가 없으며 한 곳만 변경하면됩니다.

• 맵의 내용은 런타임에 결정되며 (컴파일 타임 전에 스위치 구성의 내용이 결정되는 동안) 초기화 논리를보다 유연하거나 확장 가능하게 만들 수 있습니다.

그렇습니다. 몇 가지 장점이 있으며, 이는 더 많은 SOLID 코드를 향한 발걸음입니다. 그러나 리팩토링에 돈을 지불한다면 당신이나 당신 팀이 스스로 결정해야 할 것입니다. 디스패치 코드가 변경되지 않고 초기화 논리가 변경되며 가독성이 switch실제로 문제가되지 않으면 리팩토링이 그다지 중요하지 않을 수 있습니다.

@DocBrown의 답변에 요약 된 전략을 강력하게 선호합니다 .

나는 대답의 개선을 제안 할 것입니다.

전화

 myMap.Add(1,new Strategy1());
 myMap.Add(2,new Strategy2());
 myMap.Add(3,new Strategy3());

배포 할 수 있습니다. Open-Closed 원칙을 더 잘 준수하는 다른 전략을 추가하기 위해 동일한 파일로 돌아갈 필요가 없습니다.

Strategy1Strategy1.cpp 파일에서 구현한다고 가정 해보십시오 . 다음 코드 블록을 가질 수 있습니다.

namespace Strategy1_Impl
{
   struct Initializer
   {
      Initializer()
      {
         getMap().Add(1, new Strategy1());
      }
   };
}
using namespace Strategy1_Impl;

static Initializer initializer;

모든 StategyN.cpp 파일에서 동일한 코드를 반복 할 수 있습니다. 보시다시피, 그것은 반복되는 많은 코드가 될 것입니다. 코드 중복을 줄이려면 모든 Strategy클래스에서 액세스 할 수있는 파일에 넣을 수있는 템플릿을 사용할 수 있습니다 .

namespace StrategyHelper
{
   template <int N, typename StrategyType> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new StrategyType());
      }
   };
}

그런 다음 Strategy1.cpp에서 사용해야하는 유일한 것은 다음과 같습니다.

static StrategyHelper::Initializer<1, Strategy1> initializer;

StrategyN.cpp의 해당 라인은 다음과 같습니다.

static StrategyHelper::Initializer<N, StrategyN> initializer;

구체적인 전략 클래스의 클래스 템플리트를 사용하여 템플리트를 다른 레벨로 사용할 수 있습니다.

class Strategy { ... };

template <int N> class ConcreteStrategy;

그런 다음 대신을 Strategy1사용하십시오 ConcreteStrategy<1>.

template <> class ConcreteStrategy<1> : public Strategy { ... };

Strategys를 등록하도록 헬퍼 클래스를 변경하십시오 .

namespace StrategyHelper
{
   template <int N> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new ConcreteStrategy<N>());
      }
   };
}

Strateg1.cpp의 코드를 다음과 같이 변경하십시오.

static StrategyHelper::Initializer<1> initializer;

StrategN.cpp의 코드를 다음과 같이 변경하십시오.

static StrategyHelper::Initializer<N> initializer;