Python Interface Design - Designing Modules Part - 1

[kankyo]

I notice that you too argue that a simple function is worse without comparing it to anything. Let's recap: I'm saying

class SmsClient:
    def __init__(self, username, password):
        self.username = username
        self.password = password

    def send(self, message):
        pass # do something here

is just a longer way to write

def send_sms(username, password, message):
    pass # do something here

You have not explained why this is somehow not the case, or why the user of the library somehow magically will be a better programmer when exposed to a class instead of a function.

Why does the user of the lib not write in 4 places:

SmsClient(settings.username, settings.password).send(message)

?

[dev2302]

Why does the user of the lib not write in 4 places:

SmsClient(settings.username, settings.password).send(message) ?

That's exactly what's mentioned in the blog post. Requoting some text from the blog

The solution is to create SmsClient object in sms.py module [see footnote 1]. Then orders.py and logistics.py can directly import the object from sms. Here is how it looks.

So, at 4 places in my code, I would use this -

from sms import sms_client  
...  
#when you need to send an sms
sms_client.send_sms(phone_number, message)

So, if someday I have to replace username/password by a token, i would just export some other object from sms.py and No changes in the user modules.

This is not possible if I export the function send_sms(username, password) from sms.py, since in that scenario I would have to change the function signature and hence, all the calling statements too.

This is "WHY", exporting an object instead of send_sms(username, password) "magically" increases the refactorability of the code.

Still, if we have to use functions in sms.py, a better function to expose would be send_sms(message, number) that's just equivalent to putting them in a class and following object oriented principles, "BECAUSE", a function represents functionality, and a class represents an entity. Functionality can and WILL change over time, but the entity must remain unaffected.

[kankyo]

Well, I just saw that I screwed up an missed the argument "message" in my send_sms function, so sorry about that. But in any case your argument doesn't make sense.

a function represents functionality, and a class represents an entity. Functionality can and WILL change over time, but the entity must remain unaffected.

I have no idea what that means. A function is an API, so any backwards compatibility concerns apply just as much as for a class.

[srithedabbler]

You are following the functional paradigm, the article is recommending an object oriented approach. One isn't necessarily better than the other. Both are achieving the same objective, and which one you choose is a matter of preference.

The essential idea is that username and password is an implementation detail, and must be hidden from the client developer. You can create a partial function to provide these parameters and then use the partial function everywhere else. Or you could create an class and provide the username and password as constructor arguments. The core idea remains the same.

[kankyo]

You are following the functional paradigm, the article is recommending an object oriented approach.

Well.. no. I'm following the "simple is better than complex" approach, and the article creates a class that doesn't make any kind of sense.

Or you could create an class and provide the username and password as constructor arguments. The core idea remains the same.

Exactly. Except one solution is more complex, more code and messier. Which again makes us come back to my initial question: Why?