Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The reason for doing it is to solve the case when a newer API is no longer backwards compatible with an older API.

To explain, just say that there is an old API v1.0. The maker of this API decides it is broken and works on a new API v1.1 that intentionally breaks compatibility with the old API v1.0. Now, any programs written against the old API cannot be recompiled as-is with the new API.

Then lets say there is a large app written against the old API and the developer doesn't have access to the source code. A solution would be to re-implement a "custom" old API v1.0 in terms of the new API v1.1 calls. So the "custom" v1.0 API is actually keeping the same interface/methods as the v1.0 API but inside its implementation it is actually making calls to the new API v1.1 methods.

So the large app can be then compiled and linked against the "custom" v1.0 API and the new v1.1 API without any major source code changes.

Is there a term for this practice?

There's a recent example of this happening in Jamie Zawinski's port of XScreenSaver to the iPhone - he re-implemented the OpenGL 1.3 API in terms of the OpenGL ES 1.1 API. In this case, OpenGL 1.3 represents the "old" API and OpenGL ES 1.1 represents the "new" API.

share|improve this question
2  
API 1.0 would effectively become an adapter of API 1.1? If so, there's your answer... –  Yannis Rizos Jun 20 '12 at 2:41
2  
You need a name for your patterns book. How about Back to the Future Adapter? –  psr Jun 20 '12 at 3:05
add comment

2 Answers

up vote 6 down vote accepted

If I understand you right, you'd be implementing the adapter pattern to isolate the API calls from the rest of your application. So when the time came to switch from v1.0 to v1.1, you'd just modify your API wrapper implementation to make different calls and the rest of your application wouldn't know or care.

So your application structure would look something like this:

.----------.       .-------------.       .----------.
| Your App | ----> | API Wrapper | ----> | API v1.0 |
'----------'       '-------------'       '----------'
                              |
                              |          .----------.
                              `--------> | API v1.1 |
                                         '----------'
share|improve this answer
    
Posting my comment as an answer? Well done! ;P –  Yannis Rizos Jun 20 '12 at 2:42
    
+1 To the comment and the answer. So this is where Anna gets all her extra rep from ;) –  Gary Buyn Jun 20 '12 at 2:44
    
@YannisRizos The timestamps are almost on my side. :P –  Anna Lear Jun 20 '12 at 2:45
    
29 seconds too late is still too late! –  Yannis Rizos Jun 20 '12 at 2:46
1  
@YannisRizos c'mon other guys repost her comments as an answer, why can't Anna do the same? :) –  gnat Jun 20 '12 at 5:01
show 4 more comments

Thanks to Anna Lear and Yannis Rizos for their answer, i.e. that the API 1.0 has effectively become an adaptor for API 1.1.

I just wanted to put forward a more specific answer. In my case the API 1.0 has retained the same public interface, so the application doesn't need to change. The only thing that has changed is the internal implementation of the API 1.0 itself - it now has a dependency on the new API 1.1. So instead of "porting the application" to use API 1.1, we're "porting the API".

Porting an API

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.