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

15

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.

— Songo
source

8

Le votant peut-il expliquer pourquoi?

— Songo

J'ai entendu parler de logiciels tiers, mais pas de code tiers. La plupart des tiers ne vous donnent pas leur code source.

— Tulains Córdova

18

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é.

— M. Dudley
source

+1 pour expliquer quand une enveloppe ou une façade, si vous voulez, peut être nécessaire.

— Joshua Drake

Merci pour la réponse, mais en ce qui concerne le dernier paragraphe sur les tests unitaires, pourriez-vous jeter un coup d'œil à cette question où j'essaie de tester une classe qui dépend directement d'un framework de bibliothèque?

— Songo

@Songo: Votre stratégie de test doit être de créer une Zend_Mailmaquette que vous passez à votre Loggerobjet en cours de test. PHP ne prend-il pas en charge la saisie de canards? Si oui, ne devrait-il pas être trivial de créer un faux objet ...? Je ne connais pas vraiment PHP, mais vous pouvez consulter des exemples de bibliothèques de simulation PHP pour voir comment cela se fait généralement. Dans les langues qui ne prennent pas en charge la frappe de canard, je pense que vous devrez changer Zend_Mailpour une interface, puis créer un wrapper fin qui implémente l'interface et hérite de Zend_Mailou simplement délègue tous ses appels.

— M. Dudley

@emddudley bien oui, mais je cherchais une solution plus générale au problème dans d'autres langues qui ne prend pas en charge la frappe de canard. En fait, votre solution pour envelopper a Zend_Mailété ma première pensée, mais comme vous pouvez le voir dans mon article d'origine avant de le modifier, j'ai utilisé une interface et un wrapper qui le mettent en œuvre. Cependant, le seul but du wrapper d'exister est que je puisse me moquer de son interface. Est-ce courant dans les langues qui ne prennent pas en charge la frappe de canard? Construire un nombre infini de wrappers, je veux dire?

— Songo

@Songo: Je pense que c'est très spécifique à la langue et à la bibliothèque, et vous devez vous débrouiller avec tout ce que votre plateforme prend en charge. Parfois, vous pouvez être coincé avec des emballages d'écriture. L'injection de dépendances et la simulation d'objets sont des développements assez récents (2004?), Donc toutes les langues et bibliothèques ne les prennent pas très bien en charge. La "solution générale" que vous recherchez n'est qu'un état d'esprit: comment pouvez-vous concevoir votre code pour un couplage lâche et des tests unitaires efficaces?

— M. Dudley

6

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.

— Ben
source

Très bon point sur les tests unitaires. Je ne dis pas toujours envelopper afin de pouvoir tester votre application, mais c'est une bonne stratégie pour découpler les dépendances en cas de besoin.

— Sergio Acosta

2

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.

— Wyatt Barnett
source

2

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.

— Patkos Csaba
source

1

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

— Michael
source