Devez-vous envelopper des bibliothèques tierces que vous adoptez dans votre projet?

Question

Une discussion que j'ai eue avec un collègue aujourd'hui.

Il prétend que chaque fois que vous utilisez une 3ème partie de la bibliothèque, vous devez toujours écrire un wrapper. De sorte que vous pouvez toujours changer les choses par la suite et accueillent les choses pour votre utilisation spécifique.

Je suis en désaccord avec le mot toujours, la discussion a eu lieu concernant log4j et j'ai prétendu que log4j a bien testé et prouvé par temps de l'API et la mise en œuvre, et tout le pensable, peut être configuré de manière a posteriori et il n'y a rien que vous devez envelopper. Même si vous voulais terminer sont avérés wrappers comme commons-logging et log5j.

Un autre exemple que nous avons évoqué dans notre discussion est mise en veille prolongée. Je vous avais dit qu'il a un très gros API d'être enveloppé. En outre, il a une couche API qui vous permet de modifier son à l'intérieur si vous avez besoin. Mon ami a affirmé qu'il croit encore qu'il doit être enveloppé, mais il ne l'a pas fait en raison de la taille de l'API (ce collègue est beaucoup vétéran que moi dans notre projet actuel).

J'ai donc fait cela, et que l'emballage doit être fait dans des cas particuliers:

• vous n'êtes pas sûr de savoir comment la bibliothèque adaptée à vos besoins
• vous n'utiliser qu'une petite partie d'une bibliothèque (dans ce cas, vous ne pouvez exposer une partie de son API).
• vous n'êtes pas sûr de la qualité de la bibliothèque de l'API ou de la mise en œuvre.

J'ai aussi maintenu que, parfois, vous pouvez envelopper votre code à la place de la bibliothèque. Par exemple, les ranger votre base de données de code associé à une couche DAO, au lieu de préventivement d'emballage tout d'hibernate.

Eh bien, en fin de compte ce n'est pas vraiment une question, mais vos idées, les expériences et les opinions sont très appréciés.

Answer 1

C'est un parfait exemple pour YAGNI :

• c'est plus de travail
• ça gonfle votre projet
• cela peut compliquer votre conception
• il n'a aucun avantage immédiat
• le scénario pour lequel vous l'écrivez peut ne jamais se manifester
• dans ce cas, votre wrapper doit très probablement être réécrit complètement car il est trop étroitement lié à la bibliothèque concrète que vous utilisiez et l'API du nouveau ne correspond tout simplement pas à la vôtre.

Answer 2

Eh bien, l'avantage évident, c'est pour les technologies de commutation. Si vous avez une bibliothèque qui devient obsolète, et vous voulez échanger, vous pouvez réécrire beaucoup de code pour prendre en compte ce changement, alors que si elle était enveloppée, vous aurez un temps plus facile d'écrire une nouvelle wrapper de la nouvelle lib, que de changer tout votre code.

D'autre part, il signifie que vous devez écrire un wrapper pour chaque trivial de la bibliothèque qui vous comprennent, qui est probablement une quantité inacceptable de frais généraux.

Mon industrie est tout au sujet de vitesse, de sorte que la seule fois où j'aimerais être en mesure de justifier l'écriture d'un wrapper est si elle a été autour de quelques critiques de la bibliothèque qui était susceptible de changer de façon spectaculaire sur une base régulière. Ou, plus couramment, si j'ai besoin de prendre une nouvelle bibliothèque et chausse-pied dans l'ancien code, ce qui est malheureusement une réalité.

Ce n'est certainement pas un "toujours" de la situation. C'est quelque chose qui peut être souhaitable. Mais le temps n'est pas toujours va être là, et, en fin de compte, si l'écriture d'un gestionnaire prend des heures et à long terme, code de la bibliothèque de changements vont être quelques insignifiantes, et...Pourquoi s'embêter?

Answer 3

Je suis à peu près d'accord avec tout ce qui a été dit.

La seule fois où le code tiers est utile (barre violant YAGNI) est pour les tests unitaires.

La simulation statique et ainsi de suite vous oblige à envelopper le code, c'est une raison valable pour écrire des wrappers pour du code tiers.

Dans le cas du code de journalisation, ce n'est pas nécessaire cependant.

Answer 4

Ici, le problème est partiellement le mot 'wrapper', partiellement une fausse dichotomie, et partiellement une fausse distinction entre le JDK et tout le reste.

Le mot 'wrapper'

Emballage tout d'Hibernate, comme vous le dites, est complètement irréaliste de l'entreprise.

La restriction de la veille prolongée dépendances dans un lieu identifié, contrôlé, ensemble de fichiers source, d'autre part, peut-être bien pratique et obtenir les mêmes résultats.

La fausse dichotomie

La fausse dichotomie qui est l'incapacité à reconnaître un troisième option: normes. Si vous utiliser, disons, les annotations JPA, vous pouvez échanger Hibernate pour d'autres choses. Si vous êtes à la rédaction d'un service web et d'utiliser les annotations JAX-WS et JAX-B, vous pouvez permuter entre le JDK, CXF, Glassfish, ou quoi que ce soit.

La fausse distinction

Bien sûr, le JDK changements lentement et il est peu probable de mourir. Mais les principaux packages open source aussi changer lentement et sont peu susceptibles de mourir. Des milliers de développeurs et de projets de mise en veille prolongée. Il n'y a vraiment plus de risque d'Hibernate en train de disparaître ou de faire radicale incompatible changements de l'API qu'il ne l'est de Java lui-même.

Answer 5

Si la bibliothèque que vous êtes planification pour l'envelopper est unique dans ses "principes d'accès, des métaphores et des expressions idiomatiques" d'autres offres du même domaine, alors votre enveloppe est assez bien allez être similaire à celle de la bibliothèque et ne sera pas vous faire du bien si vous avez un jour de passer à une autre bibliothèque étant donné que vous aurez besoin d'un nouveau wrapper.

Si la bibliothèque est accessible de manière similaire à d'autres bibliothèques et de la même wrapper peut s'appliquer à ces bibliothèques, alors qu'ils sont probablement rédigé sur la base des standards et il y a de commun couche qui existe déjà pour accéder à tous les deux.

Je voudrais seulement aller avec des wrappers si je savais que j'aurais à supporter de multiples et substantiellement différentes bibliothèques de la production.