Friday Finking: Limiting parameters

[Barry Scott]

> On 13 Jul 2020, at 06:21, dn via Python-list <python-list at python.org> wrote:
> 
> On 12/07/20 10:10 PM, Barry Scott wrote:
>>> On 12 Jul 2020, at 00:15, DL Neil via Python-list <python-list at python.org <mailto:python-list at python.org>> wrote:
>>> 
>>>> That does not necessarily mean that the function needs to know
>>>> the particular representation or form of that data.   Let those be
>>>> objects with getter methods for the data you wish, and have the
>>>> function document what methods it will attempt to call.   Then
>>>> any class that provides the expected methods would be suitable.
>>> 
>>> +1
>>> 
>>> Here, the proposal is not to pass an object per-se, but to pass a function/method ("getter method") which will deliver the requisite data-items?
>>> 
>>> So, might we then find that our mailing-label routine includes something like (copy-pasting is NOT proper Python!):
>>> 
>>> def mail_label( getter ):
>>>    ...
>>>    ( first name, middle initial, last name, house number, street name,
>>>    apartment number, town, state, country, zip code ) = getter()
>>> 
>>> In which case, have we not moved the "very long list" from the function def to a later line within the routine - and how is this in some way 'better'?
>>> 
>> This is not the refactor that Roger's excellent rule-of-thumb implies.
>> Clearly moving the 20 positional args into a tuple is basically the same code,
>> and the same maintenance problem.
> 
> Agreed!
> 
> 
>> I'd expect to see something like this:
>> def mail_label( person, address ):
>> first_name = person.first_name
>> # or if you want a function interface
>> first_line_of_address = address.get_first_line()
> 
> Does this idea move whole objects across the interface? (see earlier in the thread) Taking a person class as subject and a mailing-label as the function's object, aren't there two criticisms?
> 
> 1 the function needs to know which attributes of the person and address objects it wants to use, cf saying 'I need street, number, town, ...'*

That is part of the requirements spec for the function - the function author will implement against spec so will know what is needed.

> 
> 2 "person" likely contains a load of data that is irrelevant to printing a mail-label.

The design problem we are solving is that it is easy (more maintainable) to call the function with a small number of args that provide what is needed.
Having access to more than the minimum information is not a problem usually.

One function might only need the family-name, another function the given-name (choose terms that match your region and culture here).

> 
> Why is this preferable to using a 'getter' method, or some other approach?

The idea of getter methods is to hide the implementation details of an object that may compute a value.
This is useful when refactoring and debugging, but can be over complex for a simple app/object.

person.get_name_formal() vs. person.get_name_informal() could use the same
set of data combined in different ways.

> 
> * your point (above) being that these need not be (say) a dozen data elements, but could be just-enough data, and data-combinations which identify the addressee and which represent the components of the address.

The app designer will have to design the API to person and address that makes sense in the app.

Barry