Please bear with me if the question looks not well structured.To put you in the context of my issue: I am building an application that invoices vehicles stay duration in a parking. In addition to the stay service there are some other services. Each service has its own calculation logic. Here is an illustration (please correct me if the design is wrong):public abstract class Service{   public int Id { get; set; }   public bool IsActivated { get; set; }   public string Name { get; set }   public decimal Price { get; set; }}public class VehicleService : Service{      //MTM : many to many   public virtual ICollection<MTMVehicleService> Vehicles { get; set; }}public class StayService : VehicleService{}public class Vehicle{   public int Id { get; set; }   public string ChassisNumber { get; set; }   public DateTime? EntryDate { get; set; }   public DateTime? DeliveryDate { get; set; }   //...   public virtual ICollection<MTMVehicleService> Services{ get; set; }}Now, I am focusing on the stay service as an example: I would like to know at invoicing time which class(es) would be responsible for generating the invoice item for the service and for each vehicle? This should calculate the duration cost knowing that the duration could be invoiced partially so the rule is as follows: not yet invoiced stay days * stay price per day.At this moment I have InvoiceItemsGenerator do everything but I am aware that there is a better design.
Confused about implementing Single Responsibility Principle
design patterns;object oriented;object oriented design;single responsibility;business logic
I would like to know at invoicing time which class(es) would be  responsible for generating the invoice item for the service and for  each vehicle?It seems pretty obvious that would be the responsibility of your InvoiceItemsGenerator class.Your problem is with your implementation of InvoiceItemsGenerator, which you say contains bundled within it all the business logic for the various sorts of business and their corresponding invoices, etc.Maybe try weeding through that business logic and breaking it out into discreet classes that represent the different sorts of logic and apply it -perhaps a class hierarchy with a factory method- it can be used by the InvoiceItemsGeneratorand with further refactoring, perhaps by other classes as well.Grossly oversimplified and not compilable:class BaseServiceInvoiceProcessor{  Invoice generateInvoice(){...}};class VehicleServiceInvoiceProcessor:BaseServiceInvoiceProcessor{...}class StayServiceInvoiceProcessor:BaseServiceInvoiceProcessor{...}BaseServiceInvoiceProcessor getInvoiceProcessor(enumServiceTypes serviceType){...}InvoiceItemsGenerator  {    ...   Invoice GetInvoiceByServiceType(enumServiceTypes serviceType)    {       BaseServiceInvoiceProcessor iProc= getInvoiceProcessor(serviceType);       return iProc.generateInvoice()    }    };    etc.    