Inspirado por esta pregunta Uso de bibliotecas de terceros: ¿siempre usa un contenedor? Quería saber lo que la gente realmente considera bibliotecas de terceros.
Ejemplo de PHP:
si estoy creando una aplicación usando Zend Framework, ¿debo tratar las bibliotecas Zend Framework como código de terceros?
Ejemplo de C #:
si estoy creando una aplicación de escritorio, ¿debería tratar todas las clases .Net como código de terceros?
Ejemplo de Java:
¿Debería tratar todas las bibliotecas del JDK como bibliotecas de terceros?
Algunas personas dicen que si una biblioteca es estable y no cambiará con frecuencia, entonces no es necesario ajustarla. Sin embargo, no veo cómo se probaría una clase que depende de un código de terceros sin envolverla.
Respuestas:
Sus ejemplos son todos códigos de terceros, pero no debe escribir contenedores para ellos. Son proyectos grandes y maduros con API estables y bien planificadas.
La necesidad de envoltorios es proporcionar una capa de abstracción entre su código y la biblioteca. Solo necesita esta abstracción cuando descubre que una biblioteca no proporciona buenas API para lo específico que está haciendo. Luego, puede crear el contenedor para simplificar su propio código y ocultar el hecho de que las llamadas a la API son incómodas.
Su código será verificable si usa la inyección de dependencia. En sus pruebas unitarias, puede intercambiar la dependencia de la biblioteca con un objeto simulado, lo que le permite aislar su código bajo prueba.
fuente
Zend_Mailsimulacro que pase a suLoggerobjeto bajo prueba. ¿PHP no admite la escritura de pato? Si es así, ¿no debería ser trivial crear un objeto simulado ...? Realmente no conozco PHP, pero podría ver ejemplos de bibliotecas simuladas de PHP para ver cómo se hace normalmente. En los idiomas que no admiten la escritura de pato, entonces creo que necesitaría cambiarZend_Maila una interfaz y luego crear una envoltura delgada que implemente la interfaz y heredeZend_Mailo simplemente delegue todas sus llamadas.Zend_Mailfue mi primer pensamiento, pero como puede ver en mi publicación original antes de editarlo, utilicé una interfaz y un contenedor que lo implementa. Sin embargo, el único propósito del contenedor es existir para que pueda burlarme de su interfaz. ¿Es eso común en los idiomas que no admiten la escritura de pato? ¿Construir infinito no de envoltorios quiero decir?El objetivo de concluir una biblioteca es romper la dependencia de su propio código en esa biblioteca para habilitar:
Aislar bibliotecas y marcos de terceros es solo un subconjunto de aislar el cambio.
fuente
No trataría a los miembros de la biblioteca estándar como código de terceros; después de todo, son estándar y se puede suponer razonablemente que están disponibles y son funcionales en la plataforma que está utilizando.
En cuanto a algo como Zend, creo que uno no lo envolvería; probablemente necesitaría reescribir el programa si adoptara un marco diferente. Para ser honesto, no envolvería mucho que no fuera una seria dependencia de configuración externa o si realmente no planeara hacer que esa pieza sea intercambiable.
fuente
Consideraría las bibliotecas proporcionadas por un lenguaje de programación específico como solo parte del lenguaje.
Entonces, consideraría un tercero, todas las bibliotecas proporcionadas por cualquier otra entidad como una extensión o una herramienta separada del lenguaje de programación en sí.
Tomando su ejemplo, consideraría a Zend como un tercero. También construiría mi aplicación de manera que mi lógica comercial central no dependa de Zend.
Wikipedia define un componente de terceros como:
fuente
En el sentido más estricto, cada ejemplo que dio es un código de terceros. Sin embargo, no todo el código de terceros debe estar envuelto. Todas las bibliotecas de terceros deben estar envueltas. Los marcos, por definición, no se pueden ajustar porque se convierten en parte integral de su código. Es por eso que envolvería su biblioteca de registro, pero no el marco .NET o el marco Zend. Realmente no puede separar su código de .NET, están entrelazados. Por supuesto, los buenos marcos tendrán interfaces para programar, lo que le permitirá evitar el problema hasta cierto punto.
Ver también: /programming/148747/what-is-the-difference-between-a-framework-and-a-library
fuente