Eliminate complex if else through proper software engineering principles - oop

Question

A CRM System exists where lets say there are 60 different order types for 40 different products. Processing of each order for each product is different though there may be similarities. Code for the process logic of these orders involves complex if else statements. Change in a code is extremely risky as it often breaks consistency somewhere else because of long and complex if else. It is very hard for the developer to keep track of if else.
How can the system be designed with OOP principles or otherwise, so that we can limit the the effect of code change only to that order type and product.
Update:
We sell Service(s). Services can be combined and called Bundle. Services are customizable and subcomponents can be added to it as well.
At the point of buying Services or modifying existing Services, Order is raised with the customized components specified as OrderItems. Of the OrderItems, some are MainOrderItem and rest are related to one of the MainOrderItem (Remember Bundle Services). MainOrderItem directly relates to specific Service. Other OrderItem relates to the selected subcomponents. Each OrderItem has its own Attributes and Resources.
Orders are processed differently based on Order Type. Processing of Order is in several stages that may sometimes take a day or two. The complex logic is at this point where if else conditional check happens for 40 different Order Types for 60 different Services
What in my mind is that to have the processing logic of different Order Types and Services in different classes (40 * 60 Classes) and somehow link them. At the starting point of Order processing, based on the Service and Order Type program should resolve the object of the specific class to process the order and that is the only condition check occurs. Distinct processing logic is encapsulated inside specific classes. So there is no mix in processing logic of Orders and Services. But there are some common logic shared between multiple Orders and Services which I don't want to duplicate in different classes. All of this combined is where I am looking for Ideas, Concepts and Patterns (Strategy?, Template Method?, etc...).

Answer 1

Below is just a naive example for illustration how you could approach your problem. Example takes into account only Service not Order Type as that is too vague in your question. I agree with comments below your question, that some more details are needed.
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

At a high level of abstraction, what you want to do is isolate parts of the code that vary independently in Abstractions.
So the question is, among 40 OrderType what differs and amongst 60 Service what differs ?
If the answer is we have large portfolio and it's okay to maintain 40 + 60 cases, there remains the question of combinations, 40 * 60 is huge.
So you need to refine and express how may Services interact with products, are there only a few classes of interaction, or are all 40*60 cases different ?
Possibly you want a Strategy with quite a few operations on the Abstract strategy, and then you Decorate it to express Services, as they can be combined this approach offers nice layering features.
The product itself might override some behaviors, perhaps a Bridge which is basically a Strategy++ would fit here (services vary independently from Products).