tai 348
![]() |
![]() |
![]() |
Título del Test:![]() tai 348 Descripción: patrones de diseño parte 24 |




Comentarios |
---|
NO HAY REGISTROS |
Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Un framework es un conjunto de clases cooperantes que constituyen un diseño reutilizable para una clase específica de software. Por ejemplo, un framework puede estar orientado a la construcción de editores gráficos para dominios diferentes como el dibujo o la edición de vídeo. Un framework es un conjunto de clases cooperantes que constituyen un diseño para una clase específica de software. Por ejemplo, un framework puede estar orientado a la construcción de editores gráficos para dominios diferentes como el dibujo o la edición de vídeo. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Personalizamos un framework para hacer una aplicación concreta creando subclases específicas de las clases abstractas del framework. Personalizamos un framework para hacer una aplicación concreta creando subrutinas del paradigma imperativo. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). El framework determina la arquitectura de nuestra aplicación . El framework nunca determina la arquitectura de nuestra aplicación . Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). El framework determina la arquitectura de nuestra aplicación. El framework definirá la estructura general de nuestra aplicación, su partición en clases y objetos, las responsabilidades clave, como colaboran las clases y los objetos y el hilo de control. El framework definirá solamente la estructura específica de nuestra aplicación. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). El framework determina la arquitectura de nuestra aplicación. El framework definirá la estructura general de nuestra aplicación, su partición en clases y objetos, las responsabilidades clave, como colaboran las clases y los objetos y el hilo de control. Un framework predefine estos parámetros de diseño de manera que el diseñador o el programador de la aplicación puedan concentrarse en las particularidades de dicha aplicación. Un framework no predefine estos parámetros de diseño de manera que el diseñador o el programador de la aplicación no puede concentrarse en las particularidades de dicha aplicación. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). El framework determina la arquitectura de nuestra aplicación. El framework definirá la estructura general de nuestra aplicación, su partición en clases y objetos, las responsabilidades clave, como colaboran las clases y los objetos y el hilo de control. Un framework predefine estos parámetros de diseño de manera que el diseñador o el programador de la aplicación puedan concentrarse en las particularidades de dicha aplicación. El framework representa las decisiones de diseño que son comunes al dominio de aplicación de ese framework . El framework representa las decisiones de diseño que son comunes a todos los frameworks . Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). El framework determina la arquitectura de nuestra aplicación. El framework definirá la estructura general de nuestra aplicación, su partición en clases y objetos, las responsabilidades clave, como colaboran las clases y los objetos y el hilo de control. Un framework predefine estos parámetros de diseño de manera que el diseñador o el programador de la aplicación puedan concentrarse en las particularidades de dicha aplicación. El framework representa las decisiones de diseño que son comunes al dominio de aplicación de ese framework. Los frameworks hacen hincapié así en la reutilización del diseño frente a la reutilización del código, si bien un framework incluirá normalmente subclases concretas listas para trabajar con ellas inmediatamente. Los frameworks hacen hincapié así en la reutilización del código frente a la reutilización del diseño, si bien un framework incluirá normalmente subclases concretas listas para trabajar con ellas inmediatamente. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). La reutilización que se produce al usar frameworks lleva a una inversión de control entre la aplicación y el software en que se basa. Cuando utilizamos un toolkit (o una biblioteca de subrutinas tradicional) escribimos el cuerpo principal de la aplicación y llamamos al código que queremos reutilizar. Cuando usamos un framework podemos reutilizar el cuerpo principal que nos da el framework y escribir nosotros mismos el código al que llama ese cuerpo principal. Habrá que escribir operaciones con nombres específicos y establecer convenios de llamada, pero usar un framework reduce las decisiones de diseño que hay que tomar. La reutilización que se produce al usar frameworks no invierte el control entre la aplicación y el software en que se basa. Cuando utilizamos un framework escribimos el cuerpo principal de la aplicación y llamamos al código que queremos reutilizar. Cuando usamos un toolkit (o una biblioteca de subrutinas tradicional) podemos reutilizar el cuerpo principal que nos da el framework y escribir nosotros mismos el código al que llama ese cuerpo principal. Habrá que escribir operaciones con nombres específicos y establecer convenios de llamada, pero usar un framework reduce las decisiones de diseño que hay que tomar. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Cuando usamos un framework podemos reutilizar el cuerpo principal que nos da el framework y escribir nosotros mismos el código al que llama ese cuerpo principal. Habrá que escribir operaciones con nombres específicos y establecer convenios de llamada, pero usar un framework reduce las decisiones de diseño que hay que tomar. El resultado de esto es que se pueden construir aplicaciones más rápidamente y todas las aplicaciones hechas con el mismo framework tienen estructuras parecidas, por lo que son más fáciles de mantener y resultan más consistentes para los usuarios. Por otro lado perdemos libertad creativa puesto que muchas decisiones de diseño ya vienen dadas por el framework. El resultado de esto es que las aplicaciones se construirán más lentamente y todas las aplicaciones hechas con el mismo framework tendrán estructuras totalmente distintas, por lo que serán más difíciles de mantener y resultarán más inconsistentes para los usuarios. Pero a cambio tenemos gran libertad creativa a la hora de tomar decisiones de diseño. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Indica la correcta: Si las aplicaciones son difíciles de diseñar, y los toolkits más difíciles todavía de diseñar (y construir), los frameworks son los elementos más difíciles de diseñar de todos. Si las frameworks son difíciles de diseñar, y las aplicaciones más difíciles todavía de diseñar (y construir), los frameworks son los elementos más difíciles de diseñar de todos. Si las aplicaciones son difíciles de diseñar, y los frameworks más difíciles todavía de diseñar (y construir), los toolkits son los elementos más difíciles de diseñar de todos. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Si las aplicaciones son difíciles de diseñar, y los toolkits más difíciles todavía de diseñar (y construir), los frameworks son los elementos más difíciles de diseñar de todos. Un diseñador de frameworks supone que una misma arquitectura servirá para todas las aplicaciones de ese dominio. La principal contribución de un framework a una aplicación es la arquitectura que define el framework. Por lo tanto, hay que diseñar el framework para que sea muy flexible y muy extensible. Un diseñador de frameworks supone que una misma arquitectura no servirá para todas las aplicaciones de ese dominio. La principal contribución de un framework a una aplicación son las clases específicas reutilizables que define el framework. Por lo tanto, hay que diseñar el framework para que sea muy poco flexible y muy poco extensible. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Como las aplicaciones dependen tanto del framework, son particularmente sensibles a los cambios en las interfaces del framework. Las aplicaciones que usan un framework a penas dependen de él por eso no son particularmente sensibles a los cambios en las interfaces del framework. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Como las aplicaciones dependen tanto del framework, son particularmente sensibles a los cambios en las interfaces del framework. A medida que un framework evoluciona las aplicaciones tienen que evolucionar con él; esto hace que un bajo acoplamiento sea lo más importante de todo, porque si no hasta el más mínimo cambio en el framework tendrá importantes repercusiones en la aplicación. A medida que un framework evoluciona las aplicaciones tienen que evolucionar con él; esto hace que un alto acoplamiento sea lo más importante de todo, porque si no hasta el más mínimo cambio en el framework tendrá importantes repercusiones en la aplicación. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Como las aplicaciones dependen tanto del framework, son particularmente sensibles a los cambios en las interfaces del framework. A medida que un framework evoluciona las aplicaciones tienen que evolucionar con él; esto hace que un bajo acoplamiento sea lo más importante de todo, porque si no hasta el más mínimo cambio en el framework tendrá importantes repercusiones en la aplicación. (Además como también dijimos el framework debe ser muy flexible y extensible). La forma que tiene un framework de conseguir todo esto es usando patrones de diseño. Los patrones de diseño ayudan a conseguir que la arquitectura del framework sirva para muchas aplicaciones diferentes sin necesidad de rediseño. La forma que tiene un framework de conseguir todo esto es usando patrones de diseño. Los patrones de diseño ayudan a conseguir que la arquitectura del framework sirva para muchas aplicaciones diferentes haciendo rediseño. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Una ventaja añadida es que el framework se documente con los patrones de diseño que usa. Que el framework se documente con los patrones de diseño que usa no aporta ninguna ventaja. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Una ventaja añadida es que el framework se documente con los patrones de diseño que usa. Quien conoce los patrones de diseño que usa el framework, aprende mucho más rápidamente cómo está hecho el framework. Quien conoce los patrones de diseño que usa el framework, aprende mucho más lentamente cómo está hecho el framework. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Una ventaja añadida es que el framework se documente con los patrones de diseño que usa. Quien conoce los patrones de diseño que usa el framework, aprende mucho más rápidamente cómo está hecho el framework. Incluso quienes no conocen los patrones de diseño se pueden beneficiar de la estructura que éstos proporcionan a la documentación del framework. Las personas que no conocen los patrones de diseño no se pueden beneficiar de la estructura que éstos proporcionan a la documentación del framework. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Una ventaja añadida es que el framework se documente con los patrones de diseño que usa. Quien conoce los patrones de diseño que usa el framework, aprende mucho más rápidamente cómo está hecho el framework. Incluso quienes no conocen los patrones de diseño se pueden beneficiar de la estructura que éstos proporcionan a la documentación del framework. Mejorar la documentación es importante para cualquier tipo de software, pero es particulamente importante en el caso de los frameworks, ya que suelen tener una curva de aprendizaje que es necesario superar para que comiencen a ser útiles. Mejorar la documentación es importante para cualquier tipo de software, pero no es más particulamente importante en el caso de los frameworks, ya que tienen una una curva de aprendizaje especial. Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: 3. Frameworks (marcos de trabajo). Una ventaja añadida es que el framework se documente con los patrones de diseño que usa. Quien conoce los patrones de diseño que usa el framework, aprende mucho más rápidamente cómo está hecho el framework. Incluso quienes no conocen los patrones de diseño se pueden beneficiar de la estructura que éstos proporcionan a la documentación del framework. Mejorar la documentación es importante para cualquier tipo de software, pero es particulamente importante en el caso de los frameworks, ya que suelen tener una curva de aprendizaje que es necesario superar para que comiencen a ser útiles. Si bien los patrones de diseño puede que no allanen del todo dicha curva de aprendizaje, en lo que son útiles es en hacer explícitos los elementos claves del diseño del framework, lo que hace que la curva de aprendizaje tenga menos pendiente. Si bien los patrones de diseño puede que no allanen del todo dicha curva de aprendizaje, en lo que son útiles es en hacer implícitos los elementos claves del diseño del framework, lo que hace que la curva de aprendizaje tenga menos pendiente. |