적절한 소프트웨어 엔지니어링 원칙을 통해 복잡한 것이 제거 된 경우

Question

40 가지 제품에 대해 60 가지의 주문 유형이있는 CRM 시스템이 있습니다. 유사점이 있지만 각 제품의 각 주문 처리는 다릅니다. 이러한 명령의 프로세스 논리에 대한 코드에는 복잡한 if else 문이 포함됩니다. 코드 변경은 다른 경우에는 길고 복잡하기 때문에 다른 곳에서는 일관성을 잃어 버리기 때문에 매우 위험합니다. 개발자가 다른 경우를 추적하는 것은 매우 어렵습니다.

OOP 원칙 또는 기타 방법으로 시스템을 설계 할 수 있으므로 코드 변경의 영향을 해당 주문 유형 및 제품에만 국한시킬 수 있습니다.

업데이트 :

우리는 판매 서비스 (들). 서비스을 결합하여 번들이라고 부를 수 있습니다. 서비스은 사용자 정의 할 수 있으며 하위 구성 요소도 추가 할 수 있습니다. 기존 서비스를 서비스을 구입하거나 수정하는 시점에서 은는 주문은 OrderItems에로 지정된 사용자 정의 된 구성 요소와 함께 발생합니다. OrderItem 중 일부는 이고 MainOrderItem은이고 나머지는 MainOrderItem (번들 서비스 기억) 중 하나와 관련됩니다. MainOrderItem은 (는) 특정 서비스과 직접 관련이 있습니다. 다른 OrderItem은 선택된 부속 구성 요소와 관련됩니다. 각 주문 항목에는 고유 한 이 있습니다. 속성은 및 입니다. 자원은입니다.

은 주문 유형에 따라 다르게 처리됩니다. 의 처리은 여러 단계로 이루어지며 때로는 하루나 이틀 정도 소요될 수 있습니다. 복잡한 논리는 다른 조건 검사가 60 개 종류 서비스

내 마음 속에 어떤 것은 그 다른 주문 유형 및 서비스의 처리 로직을 가지고있다 40 개 다른 주문 유형에 대해 발생하는 경우이 시점에서 다른 클래스 (40 * 60 클래스)와 어떻게 든 연결하십시오. 처리의 시작 지점에서 서비스 및 주문 유형 주문 유형을 처리하려면 프로그램이 특정 클래스의 개체를 해결해야하며 이는 유일한 조건 검사입니다. 고유 한 처리 논리는 특정 클래스 내에 캡슐화됩니다. 따라서 가공 로직에는 주문이 혼합되어 있지 않습니다. 주문 및 서비스입니다. 하지만 여러 개의 공통 논리가 복수 사이에 공유되어 있습니다.과 서비스 다른 클래스로 복제하고 싶지는 않습니다. 이 모든 것이 결합되어 아이디어, 개념 및 패턴 (전략, 템플릿 방법 등)을 찾고 있습니다.

Answer 1

다음은 문제 해결 방법을 보여주는 간단한 예입니다. 예는 귀하의 질문에서 너무 모호하기 때문에 주문 유형이 아닌 서비스만을 고려합니다.귀하의 질문에 대한 의견에 동의하며 자세한 내용이 필요합니다.

using System; 
using System.Collections; 
using System.Collections.Generic; 
using System.Linq; 

public class Program 
{ 
    public static void Main() 
    { 
     // Set-up services 
     var availableServices = new[]{ 
      new Service{ServiceId = 1, Name = "Consulting"}, 
      new Service{ServiceId = 2, Name = "Marketing"} 
     }; 

     // Set-up processors (aka DI container) 
     var processors = new Dictionary<int, IOrderProcessor> 
     { 
      {1, new ConsultingServiceProcessor()}, 
      {2, new MarketingServiceProcessor()} 
     }; 

     // Generate orders 
     var randOrderNumber = new Random(); 
     var listoOfOrders = availableServices 
      .Select(s => new Order{ 
       Service = s, 
       OrderNumber = randOrderNumber.Next(1000, 9999) 
      }) 
      .ToList(); 


     // Process orders 
     listoOfOrders 
      .ForEach(order => 
       processors[order.Service.ServiceId] 
       .Process(order)); 

    } 

    public class Service 
    { 
     public int ServiceId {get;set;} 
     public string Name {get;set;} 
    } 
    public interface IOrder 
    { 
     int OrderNumber {get;set;} 
     Service Service {get;set;} 
    } 

    public class Order : IOrder 
    { 
     public int OrderNumber {get;set;} 
     public Service Service {get;set;} 
    } 
    public interface IOrderProcessor 
    { 
     void Process(IOrder order); 
    } 
    public abstract class BaseOrderProcessor : IOrderProcessor 
    { 
     // Common data 
     public virtual void Process(IOrder order) 
     { 
      // Common logic 
      Console.WriteLine(string.Format("Base logic executed for order nr. {0}", order.OrderNumber)); 
     } 

     protected int CommonMethod() 
     { 
      return 1; 
     } 
     // Common internal logic 
    } 
    public class ConsultingServiceProcessor : BaseOrderProcessor 
    { 
     // Service specific implementation 
     public override void Process(IOrder order) 
     { 
      // Service specific logic   
      base.Process(order); // skip if not needed 

      var commonValue = CommonMethod(); 

      Console.WriteLine(string.Format("Consuling logic executed for order nr. {0}", order.OrderNumber)); 
     } 
    } 
    public class MarketingServiceProcessor : BaseOrderProcessor 
    { 
     // Service specific implementation 
     public override void Process(IOrder order) 
     { 
      // Service specific logic 

      base.Process(order); // skip if not needed 

      var commonValue = CommonMethod(); 

      Console.WriteLine(string.Format("Consuling logic executed for order nr. {0}", order.OrderNumber)); 
     } 
    } 

} 

Answer 2

높은 수준의 추상화에서는 추상화에서 독립적으로 변화하는 코드의 부분을 분리합니다.

그렇다면 40 OrderType 중 무엇이 다른지 60 서비스마다 무엇이 다른가요?

우리가 큰 포트폴리오를 가지고 있고 40 + 60 사례를 유지하는 것이 좋으면 조합의 문제가 남아 있습니다. 40 * 60은 엄청납니다.

서비스가 제품과 어떻게 상호 작용할 수 있는지, 약간의 상호 작용 클래스가 있는지, 아니면 모두 40 * 60 가지가 다른지를 명확하게하고 표현해야합니까?

아마도 추상 전략에 대한 몇 가지 작업이 포함 된 전략을 원할 수 있습니다. 그런 다음 서비스를 표현하기 위해이 전략을 결합하면 이러한 접근 방식이 좋은 계층화 기능을 제공합니다.

제품 자체가 일부 동작을 무시할 수 있습니다. 기본적으로 전략 ++ 인 Bridge가 여기 적합합니다 (서비스는 제품과 독립적으로 다릅니다).