Principio de responsabilidad única

 

El Principio de Responsabilidad Única se enfoca en el concepto de mantener una función, método o clase, enfocado en un comportamiento limitado que hace bien. Cuando pensamos en una API determinada, podemos decir que es una buena API si hace una cosa y nunca cambia. Ahora, cuando decimos API, realmente nos referimos a cualquier función, método o clase, sin embargo, todo esto es válido para el pensamiento más tradicional de lo que es una interfaz de programación de aplicaciones. Ejemplos de API populares incluyen la API de Facebook, la API de Twitter y la API de Google Plus. El principio de responsabilidad única establece que una buena interfaz de programación de aplicaciones nunca cambia. El SRP también establece que una API hace lo que dice que va a hacer, o en otras palabras, se adhiere a su contrato.

Características del principio de responsabilidad única

Ya comenzamos a hablar sobre lo que engloba una buena API. Echemos un vistazo ahora en forma de lista.

• Una buena API hace una cosa
• Una buena API nunca cambia
• Una buena API se comporta como su contrato
• Una buena API tiene una responsabilidad limitada

Parece que hay un millón de formas de expresar esto, así que aquí hay otra. Una clase debe tener una y solo una razón para cambiar. ¿Que qué? Eso no suena tan útil, ¿qué significa tener una razón para cambiar? (Malditos frikis de la programación). La forma en que entendí esto es pensar en editar código. Cuando tienes un programa y quieres cambiar su comportamiento, ¿qué haces? Busca en la fuente, encuentra dónde está el comportamiento que desea cambiar y piratea. En términos de orientación a objetos, eso podría significar una situación como la siguiente. Imagina que construyes autos personalizados y entregas este modelo a un cliente.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<?php   class Car {     public function speed()     {         return 'go fast';     }          public function steer()     {         return 'turn left';     } }   $car = new Car;   $car->speed(); // go fast $car->steer(); // turn left

Este código rompe el principio de responsabilidad única. Sabemos esto porque, ¿qué pasa si su cliente dice que solo quiere que su automóvil vaya lento y gire a la derecha? Esto es un problema ya que acaba de entregar un automóvil que solo puede ir rápido y girar a la izquierda. Así que tienes que volver al tablero de dibujo y editar tu Carclase en Dos lugares. Esta es la rotura del SRP, una clase con dos razones para cambiar . Aquí hay una forma diferente de escribir el mismo código usando varias clases. De esta manera, extraemos un comportamiento específico en su propia clase. Tendremos una Carclase que por supuesto es nuestro coche. También crearemos una Acceleratorclase y unSteeringclase. Incluso antes de escribir cualquier código, está bastante claro cuál es la responsabilidad de cada clase. De esta forma, si el cliente dice que quiere ir lento en lugar de rápido, solo cambiamos una clase. Veamos.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

<?php   class Car {     protected $speed;          public function __construct(Accelerator $speed, Steering $steer)     {         $this->speed = $speed;         $this->steer = $steer;     }          public function speed()     {         echo $this->speed->go();     }          public function steer()     {         echo $this->steer->turn();     } }   class Accelerator {     public function go()     {         return 'going fast';     } }   class Steering {     public function turn()     {         return 'turn left';     } }   $car = new Car(new Accelerator, new Steering);   $car->speed(); // going fast $car->steer(); // turn left

Entonces, en esta primera iteración, todavía tenemos el mismo comportamiento. Sin embargo, en este punto, cada clase solo tiene una razón para cambiar . Si queremos cambiar la velocidad, cambiamos la Acceleratorclase única . Si queremos cambiar de dirección, cambiamos la Steeringclase única . De esta manera, usamos un conjunto de clases para construir un objeto (¡Hola inyección de dependencia !). Cada vez que alguien viene después del hecho y pide un cambio, simplemente buscamos la clase que tiene esa responsabilidad y la cambiamos. Cambiemos de Acceleratorclase.

1 2 3 4 5 6 7

class Accelerator {     public function go()     {         return 'going slow';     } }

De esta manera, hicimos solo un cambio en una clase. Ni siquiera tenemos que tocar la Carclase. Es ajeno a estas cosas. Todo lo que sabe es que podrá llamar a un speed()método y hará lo que se supone que debe hacer. Al ejecutar nuestro código de cliente, encontramos que la velocidad de hecho ha cambiado.

1 2 3 4

$car = new Car(new Accelerator, new Steering);   $car->speed(); // going slow $car->steer(); // turn left

Ahora tenemos que arreglar la solicitud de los clientes de que Cargire a la derecha en lugar de a la izquierda. Esta es otra razón para cambiar y, como tal, no deberíamos tener que modificar la misma clase. Con nuestro código refactorizado, no tenemos que hacerlo. Simplemente buscamos la clase que se encarga de la dirección y la cambiamos una vez.

1 2 3 4 5 6 7

class Steering {     public function turn()     {         return 'turn right';     } }

Con este cambio en la clase responsable, podemos volver a ejecutar nuestro código de cliente y todo está arreglado.

1 2 3 4

$car = new Car(new Accelerator, new Steering);   $car->speed(); // going slow $car->steer(); // turn right

Ocultar la fealdad

Parte de lo que también hace este enfoque es ocultar la fealdad. Cuando todos comenzamos a codificar, pirateábamos algo de la mejor manera posible para lograr el resultado deseado. Después de un tiempo, es posible que hayamos alcanzado nuestra meta y que nuestro programa funcione. De hecho, es posible que incluso nos hayamos sentado, eché un vistazo a la monstruosidad del código en su lugar y dijimos: "Qué hermosa pieza de ingeniería".

De hecho, la belleza está en los ojos del espectador, y sabes qué, ¡ese montón de espaguetis podría ser hermoso, maldita sea! La cuestión es que gran parte de ese código sigue siendo crítico y valioso. Todo lo que estamos haciendo es esconderlo en clases que podemos inyectar en nuestro código de cliente. Hemos llegado a esperar la capacidad de hacer que suceda todo tipo de lógica con una o dos líneas simples de código. Este es el código de nivel superior. La realidad es que todavía depende del código de nivel inferior, que no es tan bonito. El código de bajo nivel está ocupado ensuciándose las manos haciendo todo el trabajo pesado por usted. Casi se siente como una corporación donde los superiores solo dan órdenes, pero en realidad no hacen nada.

Resumen del principio de responsabilidad única

El principio de responsabilidad única es realmente sencillo. Haz una cosa y hazla bien. Su gerente se lo agradecerá.