I don't think it's an either/or. I think you should use both Interfaces and Abstract Classes.
TL;DR
Abstract Classes
Pros:
- Relatively simple
- You can provide basic functionality and "hooks" that the subclasses can use.
Cons:
- You're "stuck" with the inheritance hierarchy
- Client code knows about the Base Class
Interfaces
Pros:
- Almost unlimited flexibility
Cons:
- Zero implementation provided
- May be harder for less experienced coders to understand.
Scenario
Imagine that you create an Abstract Class today. We'll call it BaseReport
. BaseReport provides an empty "save" method, and all your current types of reports extend from BaseReport and have their own implementation of save.
For the sake of argument, you also want to display the text of the report before saving it, so your BaseReport extends a simple View component provided by your language of choice that will allow you to put a few text objects and a save button on the screen and not much more. It's really lightweight, so it's a good choice based on all the reports you have in front of you. I'll call it SimpleContainer
.
Now, you're nine months down the line, and you need to have a report that has multiple pages, and someone has asked that one of the reports be viewable in either portrait or landscape modes. Neither of these requirements can be fulfilled with a subclass of SimpleContainer.
However, you have a lot of client code that knows about BaseReport, and there might even be a place or two where you've cast to SimpleContainer (where's the harm?). Not only that, the code is more like custom framework code, and you've spawned off four projects that use it. So all of those projects will have to go through QA again if you refactor to go to IReport so you can extend PagedContainer
for the one report and RotatableContainer
for the other. More than likely, at this point your answer is "sorry, we can't do that." Not because you really can't do that, but because it's too much of a risk to all the other things sitting on top of it.
But for the past 9 months, you've been developing along like gangbusters because you had that base code in BaseReport that allowed you to rip out a new Report type in record time, so you don't want to throw the baby out with the bathwater. Instead, make your BaseReport implement IReport and just make sure that the client code only refers to it as IReport. When the requirement comes in for a PagedContainer, build a BasePagedContainer that implements IReport and then build your individual reports on top.
There's not really a downside to this approach, because the amount of labor it takes to create the interface and implement it into your Abstract Classes is minuscule compared to the amount of flexibility and future-proofing you gain.
And I might have changed a few details to protect the innocent, but the scenario is real, and it happened to me. :)
Your scenario seems like you have placed an entire "message processing subsystem" inside a single function. In order to simplify the function, you will need to come up with an actual message processing subsystem consisting of several classes. Some, if not all, of these classes will need to be instantiated, allowed to run, and discarded on each invocation of your method.
This will be a subsystem which will have some state and some classes implementing operators (the actual rules.) The issue of returning multiple results is transformed into the task of modifying more than one item of state of the subsystem, and the issue of various rules interacting with each other is also transformed into having some rules modifying the state of the subsystem while other rules look at this modified state in order to figure out what to do.
Essentially, there would be a pretty close correlation between the set of local variables of your function and the set of member variables of the message processing subsystem class, though the subsystem might need to contain more member variables in order to capture information which is currently encoded in conditional branching (if
statements) in your existing method.
Needless to say, the total number of lines in such a subsystem might easily exceed your current 350 lines by a factor of 2 or 3, so, before you embark on such a refactoring, consider whether you really need it.
Best Answer
All you should ever care about is for your code to be usable, not reusable. A monkey can transform usable code to reusable code, if there are any transformations to be done at all.
The argument "I need this only here" is poor, to put it politely. The technique you're describing is often referred to as the headlines technique and is generally frowned upon.
Also relevant: Jeff Atwoods's thoughts on code folding