使用* args和** kwargs而不是显式列出预期参数

Question

When working on a project where I have a lot of nested function calls and object hierarchies I was wondering what is the best practice to pass all required parameters to the highest layer and from there step-wise to the lower layers.

Example: 3 classes with their needed (constructor) parameters:

Class A: a, b

Class B: c, d, e

Class C: f

Class A holds an instance of B and B holds an instance of C. They are initialized in the constructor of the respective parent. So this means that the one who is using my code will only initialize a new object of A and have to pass all parameters a,b,c,d,e,f to A where they are processed or further distributed.

Example code:

class A(object):
    def __init__(self, a, b, c, d, e, f):
        b = B(c, d, e, f)

class B(object):
    def __init__(self, c, d, e, f):
        c = C(f)

class C(object):
    def __init__(self, f):
        pass

My first attempt was to list all parameters that a class and all their children needs directly in the constructor, but this is very prone to errors and also has a very high code redundancy, especially when it comes to providing default values at every layer. So I am thinking of using **kwargs and *args instead.

This would have the advantage that I could just pass those to the children and every layer could just take the arguments it needs from there.

However, the disadvantage would be that someone who wants to use a class of this hierarchy could not use the IDE's auto-completion to see which parameters are expected.

What is considered the best practice in Python 3 for this?

Answer 1

Coding shouldn't be a mean to satisfy any IDE requirements, you're talking about not use the IDE's auto-completion to see which parameters are expected... Your code shouldn't be written to make your IDE happy, instead it should be easy to be uses by other coders. What does this mean? Your exposed public interfaces should be intuitive and easy to learn by people, not IDEs. I'd say one of the many requisites that good code satisfies is whether you don't even need to read any doc at all but the public interface are self-explanatory.

Here's an interesting programming quote for you to consider:

The ideal numbers of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification ‐ and then shouldn't be used anyway.

By looking at the non-relevant example you've proposed I can say straight-away that's not good OOP design, not just in terms of exposed public interfaces but also in terms of relationships (hierarchies should be created with proper reasoning). Maybe if you presented a real world-case I could advice further to make proper refactoring but with meaningless imaginary code with no use-cases and fictional meaningless parameters I don't see the point.

In any case, the best advice I can give you is about trying to come up with good encapsulated objects with proper logical relationships and thin self-explanatory public interfaces. Said otherwise, make your code "attractive" and "pleasant" to be used by others and you'll be fine :)

Answer 2

Don't think of dependency injection as something you need special support for. It's just a technique where you move logic from inside a function to outside that function. That is, instead of

class A(object):
    def __init__(self, a, b, c, d, e, f):
        b = B(c, d, e, f)

class B(object):
    def __init__(self, c, d, e, f):
        c = C(f)

class C(object):
    def __init__(self, f):
        pass

a = A(1, 2, 3, 4, 5, 6)

you write

class A(object):
    def __init__(self, a, b, bobj):
        b = bobj

class B(object):
    def __init__(self, c, d, e, cobj):
        c = cobj

class C(object):
    def __init__(self, f):
        pass

a = A(1, 2, B(3, 4, 5, C(6)))

This provides better separation, as (for example) A no longer needs to know how to create an instance of B (or, for that matter, that it even gets an instance of B ).