I love Brent Simmons’s style of responding to my last post, in which I described a cover class for NSURLSession that makes is easier for me to adopt it gradually throughout my source base. Brent:

This is the right way to do it. The callers – including the unit tests – don’t have to know anything about the implementation, since the interface is the same. That’s just good programming.

That’s just good etiquette. When responding to somebody with whom you have a fundamental difference of opinion, lead with a compliment. Brent goes on to say:

It’s also not how I would do it in this specific case.

Brent argues that cover classes have their place when it comes to adapting APIs that are not native to the frameworks or language being developed in. But when there is no impedance mismatch, he says:

I’d rather just use a thing directly, rather than write a class that wraps a built-in class.

All good food for thought. I will add here that in the particular case of my “RSLegacyHTTPRequest” class, I decided to make it a subclass of the working title for my previously mentioned “RSSpiffyRequest,” which is the much less glamorous “RSHTTPSession.” RSHTTPSession is a subclass of NSObject, and happens to own a subsystem of objects that “don’t matter to you” but deeply involve NSURLSession. In fact, interacting with RSHTTPSession will feel a lot like interacting with NSURLSession.

The idea, longer term, is that clients of RSLegacyHTTPRequest will move away from that antiquated interface and towards RSHTTPSession. The argument for subclassing in this case is I like the pattern when it allows me to gradually move good logic upwards, from an antique class to a modern class. Is it awkward that it’s called RSHTTPSession, instead of RSHTTPSessionManager? Maybe. I’ll change it if things get weird.

So I’m doing things my way, adapting an antique class to the future by providing a cover class that translates an old-and-busted interface to NSURLSession, and doing things Brent’s way, by basing the future of my “spiffy” NSURLSession convenience classes on a base class that inherits from NSObject, provides a stable interface, but fully embraces and exposes the NSURLSession philosophy to its clients.