When looking at fat interfaces like you have there, the challenge is to find the right abstraction that will allow you to break it up in reasonable chunks. The approach I look at goes something like this:
- Are there logical groupings that make sense as their own thing?
- Are there patterns that suggest separate instances?
- Is there any way I can hide some of the functions/methods?
In your particular case, it appears the second option might be a valid way to go. You have a repeating set of methods for
Matching contributions. What that suggests to me is that you actually have three instances of one interface that would look something like this:
public class TSP
You might have a parent interface that lets you get at the specific instances:
public class AllTSP
Feel free to move the
Add() methods to the root interface instead of keeping it in the TSP interface. The consumer then calls your
AllTSP instance like this:
I hope this is at least helpful enough to get your thought processes working. I wrote the sample code without any assumptions on the language you were using. If your language has properties (like C#) then the getters I put in the base interface could be implemented as properties and look a bit cleaner.
Some people can get nervous when you chain calls like this. The only way to make it really work is to guarantee that there is an object at every step in the chain. As long as the chain is short (i.e. just a couple links) then you should be fine. The danger in method chaining is that if any of the methods can return
null you will have a really hard time figuring out which one is failing. If you take proper precautions and are aware of the problems, you can make it safe.