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.

I am about to develop a ASP.NET MVC 4 project that will make use of maps. Our company has it's own map API which is very basic at the moment, but is intended to be further developed in future to match some specific customer needs. The project will have a mobile/tablet interface in addition to it's web interface and needs to be developed now. So we have planned to start use the Google Maps v3 API.

I would like to encapsulate the API, so our applications don't have Google API specific calls. The same approach as if I would like to use som external API i C# and wanted to encapsulate it in order to be able to switch API in future without having to re-code the entire application.

But I haven't been able to find similar examples, so the following questions arise:

  1. Is it a good and reasonable approach? Let me hear your pros and cons.
  2. How would it be done in practice?
share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

Is it a good and reasonable approach? Let me hear your pros and cons.

Typically, I would advise against preemptively encapsulating a library or API - it's usually a bad case of YAGNI, as it complicates your design for dubious gains. Most of the time what happens is that the wrapper ends up being tied too closely to what it's encapsulating, so that even when you actually do end up switching to some other library or API, you have to change all the client code because the new one is too different and matches very badly to your wrapper.

In this case, it might be defendable as you have relatively concrete plans of switching the underlying API and already a second implementation, albeit an incomplete one. If you do it, I would very much recommend looking closely at at least one other complete map API (like Bing Maps) to ensure your API could work with it.

How would it be done in practice?

The best approach is probably indeed a facade: don't try to write a wrapper that exposes all the functionality of Google Maps. Instead, create an interface that contains only the map-related functionality your application needs and thus represents an abstraction layer. It will probably aggregate calls as well as translating them and contain some logic of its own.

Your chances of porting it to a different map provider without having to change the application code are much better than with a thin, fully-featured wrapper.

share|improve this answer
    
Thank you for your thoughts. I totally agree that the advantage of encapsulating an API may be turned into a disadvantage in terms of longer development time (in order to encapsulate) and when you get to a API switch, it often turns out that the API interfaces are so different that you need to rewrite a lot of code anyway. So you have to be very carefull when designing your encapsulation. And I agree that the Facade pattern is the correct one to use here. –  user1632306 Feb 19 '13 at 19:13
    
What does YAGNI mean? –  user79880 Feb 26 '13 at 21:53
    
@axrwkr: if only there were some way, some sort of engine to search for websites that are relevant to a given word... –  Michael Borgwardt Feb 27 '13 at 21:46
    
@MichaelBorgwardt if you could tell me what it means then IWNTSFIOASE –  user79880 Feb 27 '13 at 22:54
add comment

If you want to simplify the first layer of the front-end development of your application, it does sound like a good and reasonable approach (if well-designed: it improves maintainability, scalability, etc.).

I believe that you want to implement a FACADE, this article here should explain just what you need: http://www.joezimjs.com/javascript/javascript-design-patterns-facade/

You can define the Facade pattern as a piece of code that simplifies a more complex interface. You can pretty much call any form of abstraction a facade.

share|improve this answer
2  
Here is a better article about facades. addyosmani.com/resources/essentialjsdesignpatterns/book/… FWIW OP does not need a facade, he needs an adapter. –  Benjamin Gruenbaum Feb 18 '13 at 20:23
    
@Benjamin Gruenbaum: actually, I'd say a facade would be much better than an adapter. An adapter is called for when your want to translate between two existing interfaces, but in this case the internal map API is still in development. –  Michael Borgwardt Feb 18 '13 at 20:58
1  
@MichaelBorgwardt I think either adapter/bridge might be a better fit than a facade. An adapter matches interfaces of different classes so classes can work together despite incompatible interfaces. A bridge separates an object's interface from its implementation so the two can vary independently. A facade is a single class that hides the complexity of an entire subsystem. I'm not sure how that applies here.Then again there is usually no point in arguing about design patterns, your opinion is as valid as mine :) –  Benjamin Gruenbaum Feb 18 '13 at 22:44
    
The truth was told here, 1st the "better article" then "your opinion is just as valid as mine" :D –  theMarceloR Feb 19 '13 at 16:55
    
Thanks for your input and especially the link for the JavaScript facade pattern. –  user1632306 Feb 19 '13 at 19:16
show 1 more 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.