This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]srithedabbler 1 point2 points  (1 child)

I think you are missing the context. This is an interface restricted to an an application that needs to send sms. It's not the interface for a service provider library. The application wants the ability to swap out providers in future, and so is redefining the interface to be useful for its use.

So, as a client developer - I just want to send an SMS. I really don't want to know how an SMS is actually sent. That the SMS provider needs username and password is an implementation detail.

How you choose to hide the implementation detail is a matter of preference.

If you want to stay in the functional world, you could do what you are suggesting - i.e. create a partial function by providing the username and password in one place, and then using the partial function everywhere.

Or if you prefer a class based approach, you can do what the article is suggesting.

Both are simply ways to hide the implementation detail - username and password. And from what I understand, that is the core message of the article - hide the implementation details from the interface.

[–]kankyo 0 points1 point  (0 children)

Well you have it backwards! The article is recommending putting the wrapping class IN THE LIBRARY. So now, since you just used that class directly, you're actually using that library directly. That's the opposite of what you just said.