objective-c - metáfora - metafora juridica ejemplos
¿Por qué se desaconsejan los marcos paraguas? (3)
En el caso de Apple, están entregando una gran cantidad de código, y esos sub-marcos a menudo se revisan por separado. Si está entregando varios gigs de frameworks, entonces puede que quiera seguir adelante y crear un marco general. Si no, probablemente no necesites la molestia.
Quiero distribuir el Marco A. El Marco A depende del Marco B. Quiero que un usuario de mi marco solo necesite incluir el Marco A, pero aún tenga acceso programático al Marco B.
Apple hace esto todo el tiempo usando el concepto de "Frameworks Umbrella", pero hay este tema en los documentos:
No crear marcos de paraguas
Si bien es posible crear frameworks paraguas utilizando Xcode, hacerlo no es necesario para la mayoría de los desarrolladores y no es recomendable. Apple usa frameworks paraguas para enmascarar algunas de las interdependencias entre bibliotecas en el sistema operativo. En casi todos los casos, debería poder incluir su código en un único paquete de marco estándar. Alternativamente, si su código era suficientemente modular, podría crear múltiples marcos, pero en ese caso, las dependencias entre los módulos serían mínimas o inexistentes y no deberían garantizar la creación de un paraguas para ellas.
¿Por qué se desaconseja este enfoque? ¿Qué lo hace una buena solución para el problema de Apple de los marcos interdependientes, pero no para el mío?
Los frameworks paraguas solo tienen sentido si usted es el único distribuidor de todos los frameworks involucrados, y estará empaquetando todos los frameworks juntos como un paquete con una sola versión que se actualizará en conjunto. Si esa es su situación, está bien, pero esta es una situación muy inusual. En el mundo del desarrollo de Cocoa, es extremadamente inusual que nadie, excepto Apple, se encuentre en esta situación.
Para el primer punto, los marcos paraguas solo tienen sentido si usted es el único distribuidor de los marcos dados. Por ejemplo, supongamos que desea incluir libcurl como parte de su marco paraguas. Ahora, algún otro empaquetador también quiere incluir libcurl como parte de su marco general. Ahora tenemos una colisión en tiempo de enlace que puede provocar errores de enlace o, peor aún, un comportamiento de tiempo de ejecución no definido. Los he perseguido yo mismo. Ellos son extremadamente desagradables. La única forma de evitar esto es que haya una sola versión de cada framework / biblioteca. Los marcos paraguas alientan lo contrario.
Incluso si solo está dividiendo su propio código en subpieces, esto significa que otros proveedores podrían usar sus sub-frameworks en sus propios frameworks paraguas, lo que les llevaría al mismo problema. Recuerde, si dice que está bien para un tercero utilizar frameworks paraguas, también está bien para otros proveedores.
Para el segundo punto, los marcos paraguas solo tienen sentido si controlas las versiones de todos los sub-frameworks. Tratar de parchar una pieza de un conjunto interdependiente de marcos es casi siempre un desastre en mi experiencia.
El proveedor del sistema operativo tiene una situación inusual debido al tamaño y la ubicuidad de su sistema. Las cosas que tienen sentido en una escala a menudo no tienen sentido en otra. NSResponder es completamente correcto al respecto. Las ventajas y desventajas son diferentes cuando se proporciona un entorno de paquete completo de miles de millones que es la base de cada programa escrito para la plataforma. Pero incluso Apple tiene solo un puñado de grandes frameworks paraguas, y siempre son contenedores de bibliotecas que proporcionan y controlan la versión de. Esto es principalmente para simplificar el trabajo de los desarrolladores que de lo contrario tendrían que buscar docenas de bibliotecas y marcos para obtener algo para compilar. Ningún tercero tiene esa situación, por lo que es muy raro que un tercero necesite esta solución. Pedirle a su cliente que vincule dos bibliotecas es completamente diferente y pedirle que vincule 20. Si proporciona 20 marcos que funcionan conjuntamente y que usted controla, entonces tal vez deba usar un paraguas, pero también puede que tenga demasiados marcos para un tercero.
La mayor parte de mi discusión aquí es en términos de OS X. En iOS no es un problema para terceros. Las bibliotecas estáticas nunca deben vincular otras bibliotecas estáticas debido a las colisiones que seguramente ocurrirán.
En teoría, la mayoría de los problemas que he discutido aquí son fundamentalmente limitaciones técnicas del enlazador. El vinculador no tiene una buena manera de administrar múltiples versiones de bibliotecas y, por lo tanto, las colisiones son un problema grave. Los ensamblados .NET intentan proporcionar más flexibilidad al respecto. No estoy lo suficientemente familiarizado con el desarrollo .NET para decir si esto ha sido exitoso o no. Mi experiencia con los sistemas grandes de componentes múltiples es que las soluciones más simples y menos flexibles son las mejores para la mayoría de los problemas. (Pero entonces, la hierba siempre es más verde ...)
Un problema es que la versión del marco B ahora está vinculada a la versión del marco A. Esto puede ser lo que quieras en algunos casos y no en otros. Si el marco B es probable que sea utilizado de forma independiente por una aplicación que también quiera utilizar el marco A, esa aplicación puede encontrarse en una situación en la que la versión de B incluida en A no es la versión que necesita o desea.
¿El framework B es un framework que una aplicación podría usar independientemente de A? Si es así, entonces puede encontrarse con este escenario. Si B es un marco que no está disponible fuera de A, entonces no debe ejecutar este escenario.