in my application I provide a Qt/C++ wrapper to certain web services based on the Danbooru software. Basically the API wraps a series of REST calls and produces / parses the JSON responses to display this in an application.
Links to the source which wraps the web API:
The basic structure of the
DanbooruService in these files involves keeping track of the "page" being shown, the filters for displaying what's being downloaded or not, and some methods that handle retrieving results from the API (cf.
getPoolList in the above links).
Now, due to the history of said web software there are a number of forks around, each with a slightly different API involved. As the one I designed now works with only two of the most popular, I thought I'd implement support for others. One of the issue is that not all web APIs support all operations.
And here we come to the question, which is at the moment more about design, than proper programming (and that's why I posted it here): what would be the "less worse" way to go about it?
This is what I'm trying at the moment:
- Avoid cramming everything in a single class as it's already too complex as it is
- Make the
*Serviceclass an abstract base class with basic methods that need to be implemented in the subclasses
- Add to the base class and to the subclasses an enum that identifies the "capabilities" of each service
- Scrap the base class idea altogether and use different classes with capabilities as point 2 above, but I'm not sure it would ease complexity.
At the moment however I'm using some hardcoded URLs for APIs, and yes, those change too between versions.
Given these requirements (I can provide some snippets inline, but I put links as the code is large), what would be a good design to make this less headache-inducing?
EDIT: Forgot to say, none of this is public, so I can break things as I want.