Liskov Substitution Principle
Generally you don’t want you method signature to vary in derived types. This can cause problems if you want to swap the use of derived types. This is often referred to as the Liskov Substitution Principle.
Benefits of Explicit Signatures
At the same time I don’t think it’s correct for all your methods to have a signature of
**kwargs. Explicit signatures:
- help to document the method through good argument names
- help to document the method by specifying which args are required and which have default values
- provide implicit validation (missing required args throw obvious exceptions)
Variable Length Arguments and Coupling
Do not mistake variable length arguments for good coupling practice. There should be a certain amount of cohesion between a parent class and derived classes otherwise they wouldn’t be related to each other. It is normal for related code to result in coupling that reflects the level of cohesion.
Places To Use Variable Length Arguments
Use of variable length arguments shouldn’t be your first option. It should be used when you have a good reason like:
- Defining a function wrapper (i.e. a decorator).
- Defining a parametric polymorphic function.
- When the arguments you can take really are completely variable (e.g. a generalized DB connection function). DB connection functions usually take a connection string in many different forms, both in single arg form, and in multi-arg form. There are also different sets of options for different databases.
Are You Doing Something Wrong?
If you find you are often creating methods which take many arguments or derived methods with different signatures you may have a bigger issue in how you’re organizing your code.