You have contradicting expectations.
On the other hand, not all microservices support all the methods and I wouldn’t want the classes to have methods that are not supported.
In other words, you want to explicitly control which methods are made available, you don’t want anything to be made available that shouldn’t be.
(…) since I still have to write a new method for every supported method.
That is the inevitable consequence from wanting to manually define the availability of each method on each service.
Either you make the defined methods blanket available and accept that some of them might not work, or you manually make sure that only the working methods are made available. Logically, there is no other choice.
But this doesn’t really solve the DRY part since I still have to write a new method for every supported method.
As was mentioned in comments by Rik D, you’ve slightly missed the mark on what DRY conveys. DRY doesn’t mean “condense your code”, it means “don’t write the same thing twice”.
I bolded “the same thing”, because just because two things look similar does not mean they are the same thing. Your two methods are not the same thing. One (A) is the base implementation of the method, and the other (B) is making A available in B’s class definition.
Those are two separate things, but they have a similar syntax since B acts as a 1-to-1 wrapper for A, which is incorrectly triggering your DRY alarm.
Your first solution
One way to solve it could be to pretend that the methods are private by adding an underscore and then just extend the ones that are supported.
“Pretending” access modifiers are different than what they are is not a good approach.
I’m no Python dev, but from what I read the “underscore prefix” approach is much more than just pretend, it actually enforces protected access to class members.
In going this route, I would suggest you first consider composition over inheritance, i.e. not deriving from
BaseAPI but instead simply injecting a
BaseAPI object in your
MyService class and then accessing its public methods directly in the
This way, you still decide which methods get expose (by deciding which
MyService methods you write), without needing to rely on inheritance.
Inheritance has its purpose, but it is often overused in cases where it isn’t necessary, and this case (inheritance which wants to be selective about what to inherit) seems to be such a case.
Your second solution
I’m a C# dev, not a Python dev, and I don’t have experience with multiple inheritance (since C# doesn’t have it). I’m no fan of multiple inheritance here (for the same reason that I’m not a fan of single inheritance in the previous paragraph), but my view on this is possibly too biased, so take it with a grain of salt.