Skip to main content

Command Palette

Search for a command to run...

Tell Don’t Ask: Principios de POO en PHP

Published
3 min read
Tell Don’t Ask: Principios de POO en PHP
F

Actualmente llevo más de 15 años en el mundo del desarrollo de software, siempre me he dedicado a mantenerme al día con todo lo relacionado a internet y el mundo de los dispositivos móviles. Soy fiel creyente de que el futuro esta en la Web. Amo la tecnología, creo que es mi mayor adicción.

Siempre me he considerado un Tech-Lover y en especial de las últimas tecnologías. Soy partidario de que en este mundo no podemos quedarnos atrás por lo que siempre hay que estar innovando y evolucionando en esta rama. Gracias a esto es que mi afán siempre ha sido el de mantenerme al día con todo lo que a tecnología se refiere.

Con el tiempo, me he dado cuenta de la importancia de las arquitecturas de software, los principios de la programación orientada a objetos y por supuesto, los patrones de diseño. Es por esto en los últimos años me he vuelto adicto a las arquitecturas de software por lo que podrás encontrar bastante información teórica y práctica en mi blog.

Tell Don’t ask es un principio de la programación orientada a objetos ( POO) que nos recuerda que no tenemos que usar los objetos para pedirles cosas o datos primero y según la información que nos devuelven tomar decisiones

Por el contrario, el principio nos sugiere es decirles a los objetos que hagan cosas y estos objetos internamente tomaran sus propias decisiones según de su estado actual.

Este principio encaja perfectamente con la idea de que un objeto se define por su comportamiento; y además es fundamental para sacar provecho al polimorfismo y la inversión de control.

Es decir si nos dedicamos a preguntar y tomar nosotros las decisiones estaremos acoplándonos, será prácticamente imposible hacer cambios al objeto en un futuro.

Estaríamos también incumpliendo el principio Open/Close” de los “principios de SOLID”, nuestro sistema será más difícil de mantener, y por lo tanto poco escalable.

Al ser expuesto el estado de una clase a las demás para que pueda ser manipulada estamos violando su encapsulamiento y por ende moviendo las responsabilidades a las clases de mayor nivel.

¿Usas GETTERS y SETTERS en tus Clases?

Si tu respuesta es sí lo mas probable es que estés inclumpliendo el principio “ Tell Don’t Ask “. Ya que por lo general tendemos a usar estos métodos de nuestras clases para asignar y devolver datos.

Por lo que entonces, desde las clases desde donde instanciemos los objetos, seguramente estaremos haciendo uso de un getter para comprobar su estado o valor, y dependiendo del esto, hacer uso del setter para modificar su estado.

Estaríamos también delegando al controlador aplicar reglas y validaciones que quizás sean de negocio y por ende deban encapsularse en nuestros objetos de clase.

Para solucionar esto, lo mejor sería utilizar métodos semánticos y aplicar el principio de “ Tell Don´t Ask “ para delegar la responsabilidad de validaciones y comprobaciones al objeto como tal, manteniendo entonces nuestros objetos encapsulados.

Ejemplo de violación del principio Tell Don´t Ask

class InvoiceController 
{
    public function payAction()
    {
        // ...     
        $userBalance = $user->getBalance();
        if ($userBalance < $invoiceTotal) {
            throw new NotEnoughFundsException();
        }

        $newBalance = $userBalance - $invoiceTotal;
        $user->setBalance($newBalance);

        // ...
    }
}

Podemos ver en el ejemplo anterior, usamos un getter ($user-&gt;getBalance()) para obtener un valor, y luego en base a ese valor, del lado del controlador, realizamos comprobaciones. Aquí estamos violando el principio.

Ejemplo correcto del principio Tell Don´t Ask

class InvoiceController
{
    public function payAction()
    {
        // ...
        try {
            $user->payInvoice($invoice);
        } catch (NotEnoughFundsException $e) {
            // ...
        }
        // ...
    }
}

Y en el objeto user, dentro del método “**payInvoice(...)**" realizar las comprobaciones pertinentes, y si todo va bien, procedemos a realizar el action requerido, de lo contrario, arrojar una excepción la cual debe ser controlada en el lado del controlador.

Y de esta forma podemos entonces aplicar este principio en nuestros desarrollo para cumplir con una arquitectura de código limpia y acoplándonos a los principios de la POO.

Recuerda que si tienes alguna sugerencia o pregunta, no dudes en dejar tus comentarios al final del post.

Si te gustó este post, ayúdame a que pueda servirle a muchas más personas, compartiendo mis contenidos en tus redes sociales.

Espero que este post haya sido de gran ayuda para ti, y como siempre, cualquier inquietud o duda que tengas, puedes contactarme por cualquiera de las vías disponibles, o dejando tus comentarios al final de este post. También puedes sugerir que temas o post te gustaría leer a futuro.

More from this blog

F

Francisco Ugalde

47 posts

Software Engineer, amante de la tecnología, la arquitectura de software y de compartir tips y contenido de valor. Siéntete libre de contactarme vía email ó Twitter.