O envolvimento de chamadas de API de terceiros é um cheiro de design?

Na verdade, acho que envolver ou isolar APIs de terceiros em uma camada "shim" é um bom design. Há uma série de vantagens em fazer isso.

Por exemplo, o que acontece se você alterar os sistemas operacionais supondo que você não está desenvolvendo em um ambiente gerenciado como o .NET (que basicamente fornece a camada shim para você)? Se você colocar uma camada de correção sobre todas as chamadas do sistema, como filas de mensagens, mutexs, etc, esse processo será muito menos doloroso. Eu usei o exemplo do sistema operacional, porque eu fiz isso, mas se aplica a qualquer tipo de biblioteca / módulo de código "swap-able". Como outro exemplo, suponha que você use uma biblioteca de gráficos e, em algum momento, decida alterar seu fornecedor. A camada de correção basicamente permite que o aplicativo principal seja executado em vários ambientes diferentes, possivelmente sem outras alterações além do que a camada de correção está realmente fazendo. Isso é muito vantajoso quando você está desenvolvendo aplicativos de plataforma cruzada. Além disso, tudo o que precisa mudar está em um local conveniente.

Eu recomendaria que você deixasse seu código como está.

No entanto, se você estiver chamando 20 métodos diferentes em código de terceiros em 1000 linhas de seu código, talvez criar uma camada fina entre você e seu código de terceiros pode poupar você (ou outra pessoa) de alguma dor o futuro, no caso em que o código de terceiros muda e você tem que atualizar todas as suas chamadas.

O motivo pelo qual você deve sempre envolver a API é:

1. A API que você está usando foi projetada para 50 usos diferentes, enquanto você escolhe apenas um deles em uso. Assim, seus protótipos de função parecerão consideravelmente diferentes porque o escopo dos projetos é diferente.
2. Como você pode escolher um escopo menor, sua API envolvida é consideravelmente mais simples e você obtém enormes benefícios de abstração ao envolvê-la
3. Obviamente, somente copiar e colar manualmente os protótipos não funcionará. Você realmente precisa simplificar.

Você descreve o padrão de Gateway . Nenhum cheiro em tudo.

...Interesting software rarely lives in isolation. Even the purest object-oriented system often has to deal with things that aren't objects, such as relational data-base tables, CICS transactions, and XML data structures.

When accessing external resources like this, you'll usually get APIs for them. However, these APIs are naturally going to be somewhat complicated because they take the nature of the resource into account. Anyone who needs to under-stand a resource needs to understand its API - whether JDBC and SQL for rela-tional databases or W3C or JDOM for XML. Not only does this make the software harder to understand, it also makes it much harder to change should you shift some data from a relational database to an XML message at some point in the future.

The answer is so common that it's hardly worth stating. Wrap all the special API code into a class whose interface looks like a regular object. Other objects access the resource through this Gateway, which translates the simple method calls into the appropriate specialized API.