BUENAS PRÁCTICAS: Programar una interfaz, no una implementacion y Favorecer la composición de objetos sobre la herencia de clase

Programar una interfaz, no una implementacion.

Es posible que hayas escuchado la frase "program to an interface, not an implementation", y te hayan dicho que es esencial seguir este principio si se quiere ser un buen programador orientado a objetos. ¿Pero qué significa exactamente? En esta publicación de blog se tratará de explicar este concepto e ilustrarlo con un ejemplo.

En esencia, el propósito de la programación de una interfaz es fomentar el acoplamiento flexible entre las clases, reduciendo la dependencia de una clase sobre otra. Esto hace que sea más fácil modificar el código en una clase sin afectar a las demás, y crea una mayor flexibilidad en el sistema.

Programando una interfaz

Imagina que eres el gerente de una empresa de software muy exitosa. Los gerentes de oficina a menudo tienen sed y necesitan una taza de café. Sin embargo, como gerente, obviamente estás demasiado ocupado como para hacer uno tú mismo, así que consigues que tu secretaria te haga uno. En el código, esto podría expresarse como:

class OfficeManager{

        public function getCoffee(){

               //instanciando una secretaria

               $secretary = new Secretary();

               //Dile a la secretaria como hacer una taza de café.

               $coffee = $secretary->getMug()

                                    ->fillWithHotWater()

                                    ->addCoffee();

               //bebe el café 

               $this->drink($coffee);

        }

}

Ahora, se puede obtener el café así:

$you = new OfficeManager();

$you->getCoffee();

Observando el código de arriba ¿Puede haber algo malo en él? ¿Qué tan flexible es este enfoque? Veamos.

Imagine que necesita su café, y llama a la secretaria como lo hace normalmente, pero espera, ¡la secretaria ha llamado y ha dicho que está enferma! ¿Qué se puede hacer? Podrías pedirle al siguiente empleado (llamémosle Eric) que se encuentra frente a tu oficina y decirle que te traiga un café, pero ¿cómo se podría hacer? El método getCoffee no tiene forma de obtener un café sin usar una secretaria. No importa cuánto quiere Eric hacerte un café, no puede, porque el método anterior no es flexible en absoluto. Este es un excelente ejemplo de programación para una implementación - está confiando en una clase "concreta" para que el programa funcione e introduce dependencias no deseadas entre los objetos.

Vamos a refactorizar el método getCoffee para aceptar un objeto empleado como argumento:

class OfficeManager{

        public function getCoffee($employee){

               //Dile al empleado como hacer una taza de café.

               $coffee = $employee->getMug()

                                   ->fillWithHotWater()

                                   ->addCoffee();

               //bebe café.

               $this->drink($coffee);

        }

}

Esta es una solución más flexible. Ahora podemos decirle a Eric que prepare un café:

$you = new OfficeManager();

$eric = new Eric();

$you->getCoffee($eric);

De hecho, si se siente particularmente sediento, podría crear una gran variedad de empleados para que le traigan café:

$you = new OfficeManager();

$employees = array(

        new Eric(),

        new Jane(),

        new George()

);

foreach($employees as $employee){

        $you->getCoffee($employee);

}

Hasta ahora bien, pero hay otro aspecto de nuestro método getCoffee que es menos que ideal. ¿Qué pasa si en el ejemplo anterior, Eric, Jane y George hicieron café de diferentes maneras? ¿Qué pasa si Jane prefiere agregar café antes del agua caliente? ¿Qué pasa si George siempre pone el café en su taza azul favorita? En la actualidad, nuestro método getCoffee limita a los empleados a una cierta forma de hacer café. Pero mientras obtenga el café, no debería importar cómo esté hecho. Tampoco hay garantía de que todos los empleados contengan los mismos métodos, por lo que el código anterior podría romperse fácilmente.

Una cosa más: ¿qué pasa si compra una nueva máquina de café para su oficina? Entonces, una clase completamente no relacionada, CoffeeMachine, podría implementar esta funcionalidad.

Hay que hacer que este método sea aún más flexible utilizando una interfaz. Una interfaz define un conjunto de métodos públicos, un contrato, que todas las clases que implementen esa interfaz deben contener.

Se comienza creando una interfaz llamada CoffeeMaker. Esta interfaz contendrá un método público llamado makeCoffee. Se garantiza que cualquier clase que implemente una interfaz contenga los métodos definidos en esa interfaz. Cualquier clase que implemente la interfaz de CoffeeMaker DEBE contener un método público llamado makeCoffee.

interface CoffeeMaker{

        public function makeCoffee();

}

Tenga en cuenta que la interfaz no define cómo debe implementarse el método makeCoffee, solo que debería haber uno. Ahora definamos algunos empleados que implementan esta interfaz. Hagamos que Eric implemente esta interfaz y, para asegurarnos de que tenemos más empleados que nos preparen un café, creemos otro empleado llamado Jane, que también implementa la interfaz de CoffeeMaker.

class Eric implements CoffeeMaker{

        public function makeCoffee(){

               $this->getMug();

               $this->addCoffee();

               $this->addHotWater();

               $this->addMilk();

               return $this->coffee;

        }

}

class Jane implements CoffeeMaker{

        public function makeCoffee(){

               $this->getMug();

               $this->addHotWater();

               $this->addMilk();

               $this->addCoffee();

               return $this->coffee;

        }

}

Como puede ver, Eric y Jane tienen una función pública llamada makeCoffee. Si no lo hicieran, se produciría un error antes de ejecutar cualquier código, porque DEBEN ajustarse a la interfaz. Ahora habrá notado que en los ejemplos anteriores, Eric y Jane implementan el método makeCoffee de forma diferente: Eric agrega el café primero, luego agrega agua caliente y luego agrega leche. Jane, por otro lado, agrega primero el agua caliente, luego la leche y luego el café. No importa cómo Eric o Jane implementen el método makeCoffee, siempre y cuando lo implementen.

Ahora, hay que refactorizar el método getCoffee de OfficeManager para lograr que los nuevos empleados hagan el café. En lugar de tomar cualquier objeto como argumento, cambiaremos el método getCoffee para aceptar un objeto de cualquier clase que implemente la interfaz de CoffeeMaker. Podemos suponer con seguridad que cualquier empleado que implemente esta interfaz tendrá un método público llamado makeCoffee.

class OfficeManager{

        public function getCoffee(CoffeeMaker $employee){

               $coffee = $employee->makeCoffee();

               $this->drinkCoffee();

        }

}

Entonces, ¿cómo se compara nuestra solución actual con el principio del "programa una interfaz, no la implementación", y por qué es mejor de lo que teníamos al principio?

Bueno, aquí hay una lista de ventajas que acabamos de incorporar a nuestro código:

• Eliminada la dependencia de la clase "concreta" secretaria
• Mayor flexibilidad: ahora se puede usar cualquier clase que implemente nuestra interfaz
• Sin dependencia de cómo se implementa el método getCoffee: podemos cambiar la forma en que los empleados preparan el café sin afectar otros aspectos del programa

Ahora esta solución es mucho más flexible de lo que teníamos que empezar.

Favorecer la composición de objetos sobre la herencia de clase

Empecemos con la definición: Herencia es cuando un objeto o clase se basa en otro objeto o clase, usando la misma implementación o comportamiento. Esto es un mecanismo para la reutilización de código para permitirnos extensiones independientes del software original mediante clases públicas e interfaces.

Por otra parte la composición quiere decir que tenemos una instancia de una clase que contiene instancias de otras clases que implementan las funciones deseadas. Es decir, estamos delegando las tareas que nos mandan a hacer a aquella pieza de código que sabe hacerlas. El código que ejecuta esa tarea concreta está sólo en esa pieza y todos delegan el ella para ejecutar dicha tarea. Por lo tanto estamos reutilizando código de nuevo.

La composición de objetos y la herencia son dos técnicas para reutilizar la funcionalidad en sistemas orientados a objetos. En general, la composición de objetos debería ser favorecida por sobre la herencia. Promueve clases más pequeñas y enfocadas y jerarquías de herencia más pequeñas.

Troels Knak-Nielsen escribió : La herencia de clase es una mezcla de dos conceptos. La clase que se extiende hereda la implementación de los padres (funciones / métodos) y hereda el tipo de los padres. En un lenguaje estático, este último es bastante importante, ya que no se pueden mezclar libremente tipos. Entonces, si algún método espera un argumento de un tipo dado, puede usar la herencia para satisfacer esto. En un lenguaje de tipado dinámico que no es un problema, simplemente puede implementar el comportamiento esperado y eso es todo. Si necesita un contrato más explícito, puede documentarlo o, dado que PHP tiene una especie de punto medio en este asunto, puede usar una interfaz estáticamente estátizada (por ejemplo, implementa Person, en lugar de extends Person) para hacer lo mismo. Dado que PHP está tipado dinámicamente, esta solución (un poco más detallada y restrictiva) es puramente opcional.

El otro uso de la herencia de clase es reutilizar la implementación. Si su Persona de la clase abstracta es extendida por una subclase Empleador, usted tendría acceso al mismo código en el Empleador como lo hace en Persona. También puede lograr la reutilización de código con la composición, pero requiere un poco más de trabajo. El empleador tendría que implementar un contenedor que delegue el control a una instancia de Persona en este caso. P.ej.:

clase Persona {

  function sayHello () {

    echo "¡Hola, mundo!";

  }

}

Empleador de clase {

  protegido $ persona;

  function __construct () {

    $ this-> person = new Person ();

  }

  function sayHello () {

    $ this-> person-> sayHello ();

  }

}

más bien que:

clase Persona {

  function sayHello () {

    echo "¡Hola, mundo!";

  }

}

clase Empleador extiende Persona {}

Como puede ver, hay un poco más de trabajo por hacer, y es por eso que las personas a menudo usan la herencia en estos casos. El costo, sin embargo, es que la relación Persona-Empleador ahora es inamovible; No se puede cambiar ni interceptar en tiempo de ejecución. También está la cuestión de la claridad. Si bien el código de composición es más detallado, también es muy claro sobre lo que hace. Puedes mirar el código y saber lo que hace. Con la versión de herencia, necesita ver la superclase para descubrir qué hace. Algunas veces hay múltiples niveles de herencia, lo que hace que rastree arriba y abajo de la cadena para averiguar exactamente qué código está disponible en la clase concreta. Finalmente, está el problema de la herencia múltiple. En PHP, no puedes. Solo tiene una oportunidad para heredar, por lo que si quiere reutilizar el código de dos lugares, bueno, no tiene suerte.

5 razones para usar composición sobre herencia en Java y OOP

En la composición, una clase que desea utilizar la funcionalidad de una clase existente no heredan, sino que contiene una referencia de esa clase en una variable miembro, por eso la composición del nombre. Las relaciones de herencia y composición también se conocen como relaciones IS-A y HAS-A. Debido a la relación IS-A, se puede pasar una instancia de subclase a un método, que acepta una instancia de superclase. Este es un tipo de Polimorfismo, que se logra usando Herencia.

Una variable de referencia de superclase puede referirse a una instancia de subclase. Al usar la composición, no obtienes este comportamiento, pero aún ofrece mucho más para modificar el equilibrio de su lado.

1) Una razón para favorecer la composición sobre la herencia en Java es que Java no admite herencia múltiple. Dado que solo puede extender una clase en Java, pero si necesita múltiples funciones como, por ejemplo, para leer y escribir datos de caracteres en archivos, necesita la funcionalidad Lector y Escritor y tenerlos como miembros privados facilita su trabajo. Eso se llama composición. Si sigue la programación para la interfaz más que el principio de implementación, y usa el tipo de clase base como variable miembro, puede usar una implementación diferente de Reader y Writer en diferentes situaciones. No obtendrá esta flexibilidad mediante el uso de herencia, en caso de extender una clase, solo obtendrá instalaciones disponibles en tiempo de compilación.

2) La composición ofrece una mejor capacidad de prueba de una clase que la herencia. Si una clase está compuesta por otra clase, puede crear fácilmente un objeto simulado representando la clase compuesta por el bien de la prueba. La herencia no proporciona este lujo. Para probar la clase derivada, debes necesitar su súper clase. Dado que las pruebas unitarias son una de las cosas más importantes a considerar durante el desarrollo del software, especialmente en el desarrollo impulsado por pruebas, la composición gana sobre la herencia.

3) Muchos patrones de diseño orientados a objetos mencionados por Gang of Four en patrones de diseño clásicos intemporales: elementos de software reutilizable orientado a objetos, favorece la composición sobre la herencia. Ejemplos clásicos de esto es el patrón de diseño de estrategia , donde la composición y la delegación se utilizan para cambiar el comportamiento del contexto, sin tocar el código de contexto. Desde el contexto utiliza la composición para mantener la estrategia, en lugar de obtenerla a través de la herencia, es fácil proporcionar una nueva implementación de la Estrategia en tiempo de ejecución. Otro buen ejemplo del uso de la composición sobre la herencia es el patrón de diseño Decorador. En el patrón Decorator , no se amplía ninguna clase para agregar funcionalidad adicional, sino que conservamos una instancia de la clase que estamos decorando y delegamos la tarea original a esa clase después de hacer la decoración. Esta es una de las mayores pruebas de elegir la composición sobre la herencia, ya que estos patrones de diseño están bien probados y probados en diferentes escenarios y resisten la prueba del tiempo, manteniéndose a la altura.

4) Aunque tanto la Composición como la Herencia le permiten reutilizar el código, una de las desventajas de la herencia es que rompe la encapsulación. Si la subclase depende del comportamiento de la superclase para su funcionamiento, de repente se vuelve frágil. Cuando el comportamiento de la superclase cambia, la funcionalidad en la subclase puede romperse, sin ningún cambio en su parte. Un ejemplo de herencia que hace que el código sea frágil es el método add () y addAll () de HashSet . Supongamos, si addAll () de HashSet se implementa llamando a add ()método y escribe una subclase de HashSet, que cifra el contenido antes de insertarlo en HashSet. Dado que hay solo un método add (), que puede insertar objetos en HashSet, usted anula estos métodos y llama a su método encrypt () anulando add () . Esto también cubre automáticamente addAll () , porque addAll () se implementa mediante add () , se ve muy atractivo. Si miras de cerca verás que esta implementación es frágil, porque se basa en el comportamiento de la clase superior. Si la clase base quiere mejorar el rendimiento e implementa addAll () sin llamar al método add () , el siguiente ejemplo se romperá.

la  clase  pública EncryptedHashSet  extiende HashSet {

    .....

    public  boolean  add (Object o) {

        return  super . agregar (cifrar (o));

    }

}

Si has usado Composición a favor de Herencia, no enfrentarás este problema y tu clase habría sido más robusta, porque ya no dependes del comportamiento de la clase superior. En su lugar, está utilizando el método de superclase para la parte de adición y se beneficiará con cualquier mejora en addAll () como se muestra en el siguiente ejemplo:

clase  pública EncryptedHashSet  implementa Set {

contenedor     privado de HashSet;

    public  boolean  add (Object o) {

        contenedor de devolución . agregar (cifrar (o));

    }

    public  boolean  addAll (Collection c) {

        return conatainer. agregar (cifrar (c));

    }

    .......

}

5. Otra razón para favorecer la composición sobre la herencia es la flexibilidad. Si usa composición, es lo suficientemente flexible como para reemplazar la implementación de la clase compuesta con una versión mejor y mejorada. Un ejemplo es el uso de la clase Comparator, que proporciona una funcionalidad de comparación. Si su objeto Container contiene un Comparador en lugar de extender un Comparador particular para comparar, es más fácil cambiar la forma en que se realiza la comparación estableciendo diferentes tipos de Comparador en instancia compuesta, mientras que en caso de herencia solo puede tener un comportamiento de comparación en tiempo de ejecución. No puedes cambiarlo en tiempo de ejecución. 

Hay muchas más razones para favorecer la composición sobre la herencia, que comenzará a descubrir una vez que comience a usar patrones de diseño. En pocas palabras, favorecer la Composición da como resultado un código más flexible y robusto que el uso de Herencia. Aunque hay algunos casos en los que el uso de herencia tiene mucho sentido, como cuando existe una verdadera relación padre-hijo, pero la mayoría de las veces tiene sentido favorecer la composición sobre la herencia para la reutilización del código. 

Grupo Python: Roberto Vilchez

                        Darwin Gonzalez