Question

I’ve written a method that looks like this:

public TimeSlotList processTimeSlots (DateTime startDT, DateTime endDT, string bookingType, IList<Booking> normalBookings, GCalBookings GCalBookings, List<DateTime> otherApiBookings) {
{

..... common process code ......

    while (utcTimeSlotStart < endDT)
    {

        if (bookingType == "x")
        {
            //process normal bookings using IList<Booking> normalBookings

        }
        else if (bookingType == "y") {

            //process google call bookings using GCalBookings GCalBookings
        }
        else if (bookingType == "z" {

            //process other apibookings using List<DateTime> otherApiBookings

        }

    }

}

So I’m calling this from 3 different places, each time passing a different booking type, and each case passing the bookings I’m interested in processing, as well as 2 empty objects that aren’t used for this booking type.

I’m not able to get bookings all into the same datatype, which would make this easier and each booking type needs to be processed differently, so I’m not sure how I can improve this.

Answer 1

If you can change the calling code, I would suggest creating separate classes for each different booking processor, with a common base class:

public abstract class BookingProcessor<TBookings> {
  public TimeSlotList ProcessTimeSlots(DateTime startDT, DateTime endDT, TBookings bookings) {
    // ..... common process code ......
    while (utcTimeSlotStart < endDT) {
      ProcessTimeSlots(utcTimeSlotStart, bookings);
      // ...
    }
  }
  protected abstract ProcessTimeSlots(DateTime utcTimeSlotStart, TBookings bookings);
}

The specific booking processors follow this pattern:

public class NormalBookingsProcessor : BookingProcessor<IList<Booking>> {
  protected override ProcessTimeSlots(DateTime utcTimeSlotStart, IList<Booking> bookings) {
    // process normal bookings using IList<Booking> normalBookings 
  }
}

This way, the code to process one type of booking is separate from the others, which is better for testability and maintainability.