Extending a Service vs. editing it

I'm tweaking some functionality in v2.3 to fit my business and I'm wondering if I'm doing it wrong.

If I want to change the code in a service, should I be editing the service or creating a new class that inherits from it?

Consider OrderTotalCalculationService:  I want to make a change to GetOrderSubtotalDiscount but the rest of the class is fine.  I could create a new service, inherit OrderTotalCalculationService, override just that function, and register it at a higher priority from the original service.  I think this is cleaner than just modifying OrderTotalCalculationService because now if I upgrade nopCommerce, I have one less merge to worry about.

But in WorkflowMessageService, let's say I want to add a new function.  How does that work when everything is running off an Interface?  Do I do the same as above but add the new signature to the interface and put a dummy implementation into the original service?  Or do I change the interface and just modify the WorkflowMessageService to add my implementation without ever creating my own subclass?

EDIT:

Should my subclasses be in their own project mirroring the nop format and those projects added to the solution?

MYBIZ.Core
MYBIZ.Domain
MYBIZ.Services

etc

Or maybe I create one new project and use those names as my namespaces inside.

I started down this road with a separate project that had partial classes to the services and interfaces I wanted to add on to.  After a while I read that you can't do partial classes across assemblies so that is out.

If I have a new interface and class that inherit from the nop versions, then register them with my own dependency registrar class with a higher Order field, will the existing nop services use my class/interface instead of the nop one, providing that the interfaces have the same name?

It looks like if I'm going to do anything to change an interface, I have to do it in a partial class in that same project.  Then the old service needs to stub out the new functions.

Then my new service sub class can implement the same interface so that solves my dependency registry question.

So far this is looking like the cleanest way to do it.

AndyMcKenna wrote:

Sorry for such a delayed response, but I've been quite busy with some other projects. When making changes consider the following questions.

1. If I were to change this class/interface is my new code the only thing taking advantage of it?
2. Does my new functionality actually belong to the type I'm extending?
3. Is what I'm about to do violate SOLID? http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29


Think about this approach maybe it will work maybe not.

interface IOldService  { 
void MethodA();
}


interface INewService : IOldService{
void MethodB()
}

class NewServiceImpl: INewService {
private IOldService _oldService;
public NewServiceImpl(IOldService oldService) {
_oldService = oldService;
}

public void MethodA() { _oldService.MethodA(); }
public void MethodB() { /* New Service code */ }

}

//Register the new service for injection
// builder.RegisterType<NewServiceImpl>().As<INewService>();

I apologize for the poor formatting. I wrote this code in the editor window but it should give you an idea how to extend the service with limited changes.

I hope this information helps you.

edit: Fixed SOLID link.