Los frameworks tienen como objetivo principal ofrecer una
funcionalidad definida, auto contenida, siendo construidos usando patrones de
diseño, y su característica principal es su alta cohesión y bajo acoplamiento.
Para acceder a esa funcionalidad, se construyen piezas, objetos, llamados
objetos calientes, que vinculan las necesidades del sistema con la
funcionalidad que este presta. Esta funcionalidad, está constituida por objetos
llamados fríos, que sufren poco o ningún cambio en la vida del framework,
permitiendo la portabilidad entre distintos sistemas.
Frameworks conocidos que
se pueden mencionar por ejemplo son Spring Framework, Hibernate,
donde lo esencial para ser denominados frameworks es estar constituidos por
objetos casi estáticos con funcionalidad definida a nivel grupo de objetos y no
como parte constitutiva de estos, por ejemplo en sus métodos, en cuyo caso se
habla de un API o librería.
Algunas características notables que se pueden
observar:
- La inversió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.
- 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.
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.
·
La inversió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.
·
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.
Fuentes de informacion : http://www.tresensocial.com/2013/04/02/social-media-framework-el-marco-de-referencia-para-la-gestion-de-la-presencia-social-media/
No hay comentarios:
Publicar un comentario