Search code examples
pythoncachingoptional-parameters

Better to have multiple methods or lots of optional parameters?


I have a class which makes requests to a remote API. I'd like to be able to reduce the number of calls I'm making. Some of the methods in my class make the same API calls (but for different reasons), so I'd like the ability for them to 'share' a cached API response.

I'm not entirely sure if it's more Pythonic to use optional parameters or to use multiple methods, as the methods have some required parameters if they are making an API call.

Here are the approches as I see them, which do you think is best?

class A:
  
  def a_method( item_id, cached_item_api_response = None):
     """ Seems awkward having to supplied item_id even 
         if cached_item_api_response is given
     """
     api_response = None 
     if cached_item_api_response:
         api_response = cached_item_api_response
     else:
         api_response = ... # make api call using item_id
     
     ... #do stuff

Or this:

class B:

    def a_method(item_id = None, cached_api_response = None):
     """ Seems awkward as it makes no sense NOT to supply EITHER
         item_id or cached_api_response
     """
     api_response = None 
     if cached_item_api_response:
         api_response = cached_item_api_response
     elif item_id:
         api_response = ... # make api call using item_id
     else:
         #ERROR

     ... #do stuff

Or is this more appropriate?

class C:
   """Seems even more awkward to have different method calls"""   

   def a_method(item_id):
      api_response = ... # make api call using item_id
      api_response_logic(api_response)

   def b_method(cached_api_response):
      api_response_logic(cached_api_response)

   def api_response_logic(api_response):
      ... # do stuff

Solution

  • Normally when writing method one could argue that a method / object should do one thing and it should do it well. If your method get more and more parameters which require more and more ifs in your code that probably means that your code is doing more then one thing. Especially if those parameters trigger totally different behavior. Instead maybe the same behavior could be produced by having different classes and having them overload methods.

    Maybe you could use something like:

    class BaseClass(object):
        def a_method(self, item_id):
            response = lookup_response(item_id)
            return response
    
    class CachingClass(BaseClass):
        def a_method(self, item_id):
            if item_id in cache:
                return item_from_cache
            return super(CachingClass, self).a_method(item_id)
    
        def uncached_method(self, item_id)
            return super(CachingClass, self).a_method(item_id)
    

    That way you can split the logic of how to lookup the response and the caching while also making it flexible for the user of the API to decide if they want the caching capabilities or not.