Los frameworks no necesariamente están ligados a un lenguaje concreto, aunque sea así en muchas ocasiones. En el cada vez más popular Ruby on Rails, ‘Ruby’ es el lenguaje de programación y ‘Rails’ el framework; por otro lado, JavaServer Faces está orientado a desarrollos en Java. Sin embargo, nada impide definir el mismo framework para lenguajes diferentes: por ejemplo, existe un framework llamado Biscuit cuyo objetivo es prácticamente convertirse en un “PHP on Rails”. Eso sí, cuanto más detallado es el framework, más necesidad tendrá de ceñirse a un lenguaje concreto.
También es posible que el framework defina una estructura para una aplicación completa, o bien sólo se centre en un aspecto de ella. Siguiendo con los ejemplos, Ruby on Rails ofrece un marco para el desarrollo completo de una aplicación web, mientras que JavaServer Faces está más orientado a la interfaz de usuario.
Sin embargo, a medida que la aplicación crece, un programador competente procurará seguir unas determinadas pautas que le faciliten su trabajo de desarrollo y mantenimiento: separación de presentación y lógica, una sintaxis coherente, etc. La evolución natural sera hacia que, de algún modo, se construirá su propio framework.
Y en vez de definir un estándar, ¿por qué no utilizar uno ya definido, y aprovechar el trabajo de otros muchos desarrolladores? Hacer un desarrollo críptico y difícil de interpretar puede ser útil en un concurso de código ofuscado o para presumir de “gurú”, pero es muy poco útil para desarrollar y mantener una aplicación. El coste inicial (la curva de aprendizaje) de utilizar un framework se compense probablemente en cuanto el trabajo de desarrollo crezca mínimamente.
También es posible que el framework defina una estructura para una aplicación completa, o bien sólo se centre en un aspecto de ella. Siguiendo con los ejemplos, Ruby on Rails ofrece un marco para el desarrollo completo de una aplicación web, mientras que JavaServer Faces está más orientado a la interfaz de usuario.
Sin embargo, a medida que la aplicación crece, un programador competente procurará seguir unas determinadas pautas que le faciliten su trabajo de desarrollo y mantenimiento: separación de presentación y lógica, una sintaxis coherente, etc. La evolución natural sera hacia que, de algún modo, se construirá su propio framework.
Y en vez de definir un estándar, ¿por qué no utilizar uno ya definido, y aprovechar el trabajo de otros muchos desarrolladores? Hacer un desarrollo críptico y difícil de interpretar puede ser útil en un concurso de código ofuscado o para presumir de “gurú”, pero es muy poco útil para desarrollar y mantener una aplicación. El coste inicial (la curva de aprendizaje) de utilizar un framework se compense probablemente en cuanto el trabajo de desarrollo crezca mínimamente.
- Lainversión de control: En un frame, a diferencia de las bibliotecas, el flujo de control no es dictado por el programa que llama, sino por el mismo.1
- La funcionalidad o comportamiento predeterminado: Un marco tiene un comportamiento predeterminado. Este comportamiento por defecto debe ser un comportamiento útil, definido e identificable.
- Su extensibilidad : Un marco puede ser ampliado para proporcionar una funcionalidad específica. El frame, en general, no se supone que deba ser modificado, excepto en cuanto a extensibilidad. Los usuarios pueden ampliar sus características, pero no deben ni necesitan modificar su código.
No hay comentarios.:
Publicar un comentario