State - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-07-13T13:25:43Z

Texto reemplazado: «<div align="justify">» por «»

Marilyn06021 may.jc en 13:17 23 abr 2012

2012-04-23T13:17:37Z

Cinformiju jc en 15:49 23 mar 2012

2012-03-23T15:49:31Z

Yalexy idict en 14:52 20 feb 2012

2012-02-20T14:52:43Z

Yaucp03038jcscu: Página creada con ' {{Definición |nombre=State |imagen= UMLClassDiagram02.gif |tamaño= |concepto= Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.}}
2012-02-19T19:12:41Z

Página creada con ' {{Definición |nombre=State |imagen= UMLClassDiagram02.gif |tamaño= |concepto= Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.}} <d...'

Página nueva

{{Definición
|nombre=State
|imagen= UMLClassDiagram02.gif
|tamaño=
|concepto= Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.}}
<div align="justify">
''' State. ''' El patrón de diseño Iterator se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo, dando así la impresión de que el objeto cambia de clase.

==Como usarlo==

Cuando el comportamiento de un objeto depende de su estado y debe poder cambiar dinámicamente (en tiempo de ejecución) dicho comportamiento, a medida que cambie dicho estado.
Cuando las operaciones tienen definiciones largas y con múltiples condiciones, dependientes del estado del objeto, siendo lo más adecuado separar en objetos independientes cada [[condición atómica]], para poder así combinarlas y modificarlas independientemente, ya sea en estados ya existentes, ya en otros nuevos que se formen combinándolos.

==Ventajas==

Dado que el comportamiento específico de cada estado está autocontenido en cada estado concreto, existe una gran flexibilidad para añadir nuevos estados y transiciones, mediante la definición de nuevas subclases.
A pesar de que la distribución del comportamiento ante diferentes situaciones entre diferentes objetos incrementa el nº de clases y reduce la compacidad, es la mejor solución cuando hay muchos estados, pues evita las definiciones multicondicionales y grandes, tan indeseables como los procedimientos gigantes lo son en el estilo imperativo.
Se hacen más explícitas las transiciones entre estados que sí todo estuviera concentrado en una sola clase (esto hace más inteligible el diseño), impidiendo además los estados internos inconsistentes (desde el punto de vista del contexto, los cambios de estado son ATÓMICOS).
Si los objetos que representan los estados no tienen variables de instancia (esto es, el estado está totalmente definido en su propio tipo) entonces diferentes contextos pueden compartir estados, como PesoMosca sin estado intrínseco, sólo comportamiento.

==Relacionado con==

PesoMosca explica como los objetos Estado pueden ser compartidos.
Los objetos Estado a menudo son Solitarios.

==Otros aspectos de interés==

La misión de Contexto es definir la interfaz que interesa a los clientes, mientras mantiene una referencia al Estado actual. Si dicho Estado necesita tener acceso al Contexto al que está asociado, éste puede pasarse a si mismo como parámetro de la petición.
Si los estados que van a hacer falta no se conocen a priori y el Contexto cambia de Estado poco frecuentemente, es mejor ir creando/destruyendo estados sobre la marcha. Pero si el Contexto cambia constantemente de Estado es preferible crear todos los estados al comienzo y no destruirlos nunca (puede volver a hacer falta).
Las transiciones entre estados pueden estar prefijadas a priori en el Contexto o pueden dejarse a la responsabilidad de cada estado, que tendrá entonces que saber quien le sucede (aparte de este inconveniente, esta solución es más flexible y, por ello, preferible). Otra alternativa es una transición entre estados definida tabularmente. Esto permite cambiar el criterio de transición cambiando solamente los datos de entrada, pero es menos eficiente, hace menos explícitas las transiciones entre estados y dificulta el añadir acciones a dichas transiciones.
Algunos lenguajes (Self) permiten a un objeto cambiar de clase en tiempo de ejecución, en lo que constituye una especie de [[herencia dinámica]]; esto es, soportan directamente este patrón.

==Fuentes==

[http://es.wikipedia.org/wiki/State_(patrón_de_diseño) wikipedia.org]
[http://patronesdediseno.blogspot.com/2009/05/patron-state.html patronesdedieseno.blogspot.com]
[http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php ingenierosoftware.com]
[http://www.danielcostas.com/patrones-de-diseno/ danielcostas.com]

[[Category: Informática]][[Category:Programación]]

@@ Línea 1: / Línea 1: @@
 {{Definición
 |nombre=State
@@ Línea 24: / Línea 23: @@
 *Las transiciones entre estados pueden estar prefijadas a priori en el Contexto o pueden dejarse a la responsabilidad de cada estado, que tendrá entonces que saber quien le sucede (aparte de este inconveniente, esta solución es más flexible y, por ello, preferible).  Otra alternativa es una transición entre estados definida tabularmente.  Esto permite cambiar el criterio de transición cambiando solamente los datos de entrada, pero es menos eficiente, hace menos explícitas las transiciones entre estados y dificulta el añadir acciones a dichas transiciones.
 *Algunos lenguajes (Self) permiten a un objeto cambiar de clase en tiempo de ejecución, en lo que constituye una especie de [[herencia dinámica]]; esto es, soportan directamente este patrón.
-−
 ==Fuentes==
 *[http://es.wikipedia.org/wiki/State_(patrón_de_diseño) wikipedia.org]
 *[http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php ingenierosoftware.com]
 *[http://www.danielcostas.com/patrones-de-diseno/ danielcostas.com]
 [[Category: Informática]][[Category:Programación]][[Category:Patrones_de_diseño]]

@@ Línea 19: / Línea 19: @@
 *PesoMosca explica como los objetos Estado pueden ser compartidos.
 *Los objetos Estado a menudo son Solitarios.
- ==Otros aspectos de interés==
+==Otros aspectos de interés==
 *La misión de Contexto es definir la interfaz que interesa a los clientes, mientras mantiene una referencia al Estado actual.  Si dicho Estado necesita tener acceso al Contexto al que está asociado, éste puede pasarse a si mismo como parámetro de la petición.
 *Si los estados que van a hacer falta no se conocen a priori y el Contexto cambia de Estado poco frecuentemente, es mejor ir creando/destruyendo estados sobre la marcha.  Pero si el Contexto cambia constantemente de Estado es preferible crear todos los estados al comienzo y no destruirlos nunca (puede volver a hacer falta).

@@ Línea 1: / Línea 1: @@
+{{Normalizar}}
 {{Definición
 |nombre=State
@@ Línea 6: / Línea 6: @@
 |concepto= Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.}}
 <div align="justify">
-''' State. ''' El patrón de diseño  Iterator se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo, dando así la impresión de que el objeto cambia de clase.
+''' State. ''' El patrón de diseño Iterator se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo, dando así la impresión de que el objeto cambia de clase.
 *Cuando el comportamiento de un objeto depende de su estado y debe poder cambiar dinámicamente (en tiempo de ejecución) dicho comportamiento, a medida que cambie dicho estado.
-*Cuando las operaciones tienen definiciones largas y con múltiples condiciones, dependientes del estado del objeto, siendo lo más adecuado separar en objetos independientes cada [[condición atómica]], para poder así combinarlas y modificarlas independientemente, ya sea en estados ya existentes, ya en otros nuevos que se formen combinándolos.
+*Cuando las operaciones tienen definiciones largas y con múltiples condiciones, dependientes del estado del objeto, siendo lo más adecuado separar en objetos independientes cada condición atómica, para poder así combinarlas y modificarlas independientemente, ya sea en estados ya existentes, ya en otros nuevos que se formen combinándolos.
 ==Ventajas==
 *Dado que el comportamiento específico de cada estado está autocontenido en cada estado concreto, existe una gran flexibilidad para añadir nuevos estados y transiciones, mediante la definición de nuevas subclases.
 *A pesar de que la distribución del comportamiento ante diferentes situaciones entre diferentes objetos incrementa el nº de clases y reduce la compacidad, es la mejor solución cuando hay muchos estados, pues evita las definiciones multicondicionales y grandes, tan indeseables como los procedimientos gigantes lo son en el estilo imperativo.
-*Se hacen más explícitas las transiciones entre estados que sí todo estuviera concentrado en una sola clase (esto hace más inteligible el diseño), impidiendo además los estados internos inconsistentes (desde el punto de vista del contexto, los cambios de estado son ATÓMICOS).
+*Se hacen más explícitas las transiciones entre estados que sí todo estuviera concentrado en una sola clase (esto hace más inteligible el diseño), impidiendo además los estados internos inconsistentes (desde el punto de vista del contexto, los cambios de estado son atómicos.
 *Si los objetos que representan los estados no tienen variables de instancia (esto es, el estado está totalmente definido en su propio tipo) entonces diferentes contextos pueden compartir estados, como PesoMosca sin estado intrínseco, sólo comportamiento.
 ==Relacionado con==
 *PesoMosca explica como los objetos Estado pueden ser compartidos.
 *Los objetos Estado a menudo son Solitarios.
   ==Otros aspectos de interés==
 *La misión de Contexto es definir la interfaz que interesa a los clientes, mientras mantiene una referencia al Estado actual.  Si dicho Estado necesita tener acceso al Contexto al que está asociado, éste puede pasarse a si mismo como parámetro de la petición.
@@ Línea 40: / Línea 34: @@
-[[Category: Informática]][[Category:Programación]]
+[[Category: Informática]][[Category:Programación]][[Category:Patrones_de_diseño]]

State - Historial de revisiones

Javiermartin jc: Texto reemplazado: «» por «»

Marilyn06021 may.jc en 13:17 23 abr 2012

Cinformiju jc en 15:49 23 mar 2012

Yalexy idict en 14:52 20 feb 2012

Javiermartin jc: Texto reemplazado: «
» por «»