Qu'est-ce qui est considéré comme un code tiers?

Inspiré par cette question Utilisation de bibliothèques tierces - utilisez-vous toujours un wrapper? Je voulais savoir ce que les gens considèrent réellement comme des bibliothèques tierces.

Exemple de PHP:
si je crée une application utilisant le framework Zend, dois-je traiter les bibliothèques du framework Zend comme du code tiers?

Exemple de C #:
si je crée une application de bureau, dois-je traiter toutes les classes .Net comme du code tiers?

Exemple de Java:
dois-je traiter toutes les bibliothèques du JDK comme des bibliothèques tierces?

Certaines personnes disent que si une bibliothèque est stable et ne changera pas souvent, il n'est pas nécessaire de l'envelopper. Cependant, je ne vois pas comment on pourrait tester une classe qui dépend d'un code tiers sans l'encapsuler.

Vos exemples sont tous du code tiers, mais vous ne devez pas écrire de wrappers pour eux. Ce sont de grands projets matures avec des API stables et bien planifiées.

Le besoin de wrappers est de fournir une couche d'abstraction entre votre code et la bibliothèque. Vous n'avez besoin de cette abstraction que lorsque vous découvrez qu'une bibliothèque ne fournit pas de bonnes API pour la chose spécifique que vous faites. Ensuite, vous pouvez créer l'encapsuleur pour simplifier votre propre code et masquer le fait que les appels d'API sont maladroits.

Votre code sera testable si vous utilisez l'injection de dépendance. Dans vos tests unitaires, vous pouvez échanger la dépendance de la bibliothèque avec un objet factice, ce qui vous permet d'isoler votre code testé.

Le but de conclure une bibliothèque est de briser la dépendance de votre propre code sur cette bibliothèque afin d'activer:

• Test unitaire - Vous devez pouvoir tester votre code. Si une bibliothèque ne vous permet pas de se moquer des classes ou de forcer les réponses dont vous avez besoin pour votre test, vous devrez envelopper cette bibliothèque. C'est un problème évident, et ce n'est probablement pas le cas dont vous vous interrogez.
• Modification des implémentations - En tant qu'auteur de code, vous devez comprendre les changements qui se présenteront probablement et combien ces changements coûteront à préparer par rapport à leur probabilité. Pouvez-vous passer de .NET à JVM? C'est difficile et peu probable; cependant, vous êtes très susceptible de changer les technologies d'interface utilisateur à l'avenir, ou les moteurs XML.

L'isolement des bibliothèques et des frameworks tiers n'est qu'un sous-ensemble du changement d'isolement.

Je ne traiterais pas les membres de la bibliothèque standard comme du code tiers - ils sont après tout standard et peuvent raisonnablement être supposés être disponibles et fonctionnels sur la plate-forme que vous utilisez.

Quant à quelque chose comme Zend, je pense que l'on ne l'envelopperait pas - vous auriez probablement besoin de réécrire le programme si vous preniez un cadre différent. Pour être honnête, je n'emballerais pas grand chose qui ne soit pas une dépendance de configuration externe sérieuse ou si je n'avais pas vraiment l'intention de rendre cette pièce échangeable.

Je considérerais les bibliothèques fournies par un langage de programmation spécifique comme faisant simplement partie du langage.

Ensuite, je considérerais un tiers, toutes les bibliothèques fournies par toute autre entité comme une extension ou un outil distinct du langage de programmation lui-même.

En prenant votre exemple, je considérerais Zend comme un tiers. Je construirais également mon application de manière à ce que ma logique métier principale ne dépende pas de Zend.

Wikipedia définit le composant tiers comme:

En programmation informatique, un composant logiciel tiers est un composant logiciel réutilisable développé pour être distribué librement ou vendu par une entité autre que le fournisseur d'origine de la plateforme de développement.

Au sens strict, chaque exemple que vous avez donné est un code tiers. Cependant, tous les codes tiers ne doivent pas être encapsulés. Toutes les bibliothèques tierces doivent être encapsulées. Les cadres, par définition, ne peuvent pas être encapsulés car ils font partie intégrante de votre code. C'est pourquoi vous emballeriez votre bibliothèque de journalisation, mais pas le framework .NET ou le framework Zend. Vous ne pouvez pas vraiment séparer votre code de .NET - ils sont entrelacés. Bien sûr, de bons cadres auront des interfaces pour programmer, vous permettant de contourner le problème dans une certaine mesure.

Voir aussi: /programming/148747/what-is-the-difference-between-a-framework-and-a-library