Strategy
El patrón de diseño Strategy es de los más cruciales que existen en el diseño orientado a objetos. Se trata de crear componentes conectables, reemplazables y reusables.
Para explicar este patrón vamos a usar un ejemplo simple, que dicho sea de paso el uso de este patrón excede al ejemplo, pero es un buen intento para ayudar a comprenderlo.
Hola Mundo usando Strategy
El diagrama de clases UML muestra que la clase padre implementa las funciones genéricas representando las etiquetas HTML de inicio y fin. La clase hija HolaMundo implementa las funciones específicas, representado por el contenido del documento. De esta manera, para generar algo más que un saludo, digamos un anuncio, podemos agregar otra clase hija, la cuál genera contenido de un anuncio.
Podemos mover el método getContents( ) a un objeto tipo Strategy, el cual utiliza HtmlDocument directamente en lugar de utilizar una subclase HtmlDocument. Tal y cómo lo muestra la siguiente figura.
Cabe recalcar que estamos usando este ejemplo solo para entender los aspectos mecánicos de este patrón. HtmlContentStrategy podría ser también una clase abstracta, pero lo hemos definido como una interfaz para dejar en claro que éste no necesita tener código.
Ahora veamos como pinta esto en código. La clase HtmlDocument todavía genera el inicio y comienzo del documento. Pero en lugar de obtener el contenido de un método que es aplicado en una subclase, éste lo obtiene del objeto Strategy.
Class HtmlDocument
{
prívate $strategy;
public function __construct( $strategy )
{
$this->strategy = $strategy;
}
public function getHtml( )
{
return “<html><body>â€.$this->strategy->getContents( ).â€</body></html>â€;
}
}
Queremos poder conectar diferentes objetos Strategy dentro del objeto HtmlDocument. Por lo que, el objeto HtmlDocument necesita una forma consistente de llamar al objeto Strategy. En otras palabras, éste necesita una interfaz consistente, la cuál es definidad por una interface.
interface HtmlContentStrategy
{
public function __construct( $name );
public function getContents( );
}Ahora cualquier objeto HtmlDocument podrá usar cualquier objeto Strategy que implemente esta interfaz, ya que él solo requiere la habilidad para llamar al método getContents( ).
Pero, ¿qué pasa con el constructor? La interfaz lo define, también. El objeto Strategy para generar el mensaje “Hola Mundo†necesita la palabra “Mundo†como argumento en el constructor. Pero, ¿estamos seguros que otro objeto necesitará la misma palabra? Me temo que no; de hecho, pienso que necesitarán todo tipo de información para hacer su trabajo.
Para contrarestar este problema, solo eliminamos el constructor de la interface. Desde que HtmlDocument no instancia la clase Strategy, todos los objetos que implementan la interfaz pueden ser usados aún y cuando los constructores difieren. Así que la interfaz solo necesita el método getContents( ).
interface HtmlContentStrategy
{
public function getContents( );
}Ahora podemos implementar el “Hola Mundo†como una clase Strategy:
class HolaMundoStrategy implements HtmlContentStrategy
{
var $mensaje;
public function __construct( $mensaje )
{
$this->mensaje = $mensaje;
}
public function getContents( )
{
return "Hola ".$this->mensaje . "!";
}
}Lo que esta clase hace es trivial, pero el patrón es extremadamente usable en situaciones más complejas.
Listo:p
Ya quedó, muchas gracias =)