I have a communication class that incapsulates all the apis of a remote application. This class happens to be a delegate class because it is interchangeable with another one (the remote application has two different channels).
This class has a number of topics (eg: acknowledge, people, invoices, duedates, payment methods, queues), and each topic has a number of methods (setOne, getOne, getAll, doSomething...). The number of topics is raising rapidly recently, from 1-2 to 6 and possibly more in the future.
Considering that the class itself needs some scaffolding methods (configuration, startup, authentication...) and each topic needs some auxiliary protected method, the total projected number of method is rasing beyond my confort zone.
If this class wasn't itself a delegate class, I would have implemented this solution: a class for each topic, each making use of the common class, and if necessary of the others. But the client code wants to be given just ONE class to which make requests.
One option is to make a single delegate class with lots of relay methods to composite objects. But I don't feel this is very far from swallowing the frog and just have a big class full of stuff.
Are there other solutions?
I'm working in php and I colud leverage the ___CALL meta method: class accepts any message and then looks up (via reflection) if it has an auxiliary class to relay the calling. This could be smart, but I would leave this solution for emergencies.