通過適當的軟件工程原理消除複雜的情況

Question

CRM系統存在的地方可以說有40種不同的產品有60種不同的訂單類型。雖然可能有相似之處，但每個產品的每個訂單的處理都是不同的。這些訂單的過程邏輯代碼涉及複雜的if else語句。代碼的變化是非常危險的，因爲它往往會在其他地方破壞一致性，因爲如果其他情況很長並且很複雜。開發者很難跟蹤其他情況。

系統如何設計爲符合OOP原則或其他方式，以便我們可以將代碼更改的效果僅限於該訂單類型和產品。

更新：

我們賣服務（S）。 服務可以合併，並稱爲捆綁。 服務是可定製的，子組件也可以添加到它。 在購買服務或修改現有服務點，訂購上升指定爲的OrderItems定製的組件。在OrderItems中，有些是MainOrderItem，其餘與MainOrderItem（記住捆綁服務）中的一個有關。 MainOrderItem直接關係到具體的服務。其他OrderItem與選定的子組件有關。每個訂單項有它自己的屬性和資源。

訂單的處理方式根據不同訂單類型。處理訂單處於幾個階段，有時可能需要一兩天。複雜的邏輯是在這一點上，如果其他條件檢查發生了40種不同的訂單類型 60個不同服務

在我心中是什麼有不同的定單類型和服務的處理邏輯，其中在不同的類（40 * 60類），並以某種方式鏈接它們。在起始點訂單處理中，基於服務和訂單類型程序應解析特定類的對象來處理訂單，這是唯一的條件檢查發生。不同的處理邏輯封裝在特定的類中。所以在處理邏輯訂單和服務沒有混合。但有一些共同的邏輯共享訂單和服務，我不想在不同的類重複。所有這些加在一起就是我在尋找想法，概念和模式（策略？，模板方法？等等）的地方。

Answer 1

下面只是一個簡單的例子，說明你如何解決你的問題。示例僅考慮Service not Order Type，因爲您的問題中含義太模糊。我同意你的問題下面的評論，需要更多的細節。

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個案例都不同？

可能你需要一個策略，在抽象策略上有很多操作，然後你將它裝飾成表示服務，因爲它們可以結合使用，這種方法提供了很好的分層功能。

產品本身可能會覆蓋一些行爲，也許是一個基本上是Strategy ++的橋樑（適用於各種產品）。