Chemaclass - php

Recipes for Decoupling

2022-11-28T00:00:00+00:00

¿Qué es el acoplamiento y por qué nos perjudica? ¿Cómo desacoplar de forma eficiente? Este libro recopila estrategias para separar tu código de dominio de los detalles de infraestructura. El resultado: un sistema más sano a largo plazo.

Aprenderás a crear reglas de PHPStan desde cero. Además, el libro te guía por múltiples oportunidades de desacoplamiento:

framework web
frameworks cli
validación de formularios
orm y base de datos
framework de testing

Lee más sobre el libro: matthiasnoback.nl/book/recipes-for-decoupling/

Cómpralo aquí: leanpub.com/recipes-for-decoupling

Phel: el Lisp que Compila a PHP

2021-02-01T00:00:00+00:00

Un nuevo lenguaje de Programación Funcional construido sobre el ecosistema de PHP.

El Lenguaje Phel #

Phel es un lenguaje de Programación Funcional (FP) que compila a PHP. Es un dialecto de Lisp inspirado en Clojure y Janet.

Características #

Construido sobre el ecosistema de PHP
Buenos reportes de errores
Diferentes estructuras de datos (Arrays, Tables y Tuples)
Macros
Funciones recursivas
Sintaxis potente pero simple
REPL

¿Por qué Phel? #

Phel lo creó Jens Haase. Como menciona en el sitio web, “es el resultado de muchos intentos fallidos de hacer programación funcional en PHP”. Buscaba algo con estas características:

Inspirado en LISP
Lenguaje de Programación Funcional
Que funcione en proveedores de hosting baratos
Sea fácil de escribir y depurar

A finales de mayo de 2020 terminé el libro Seven Languages in Seven Weeks, donde aprendí los fundamentos de Prolog, Erlang, Clojure, Haskell… Incluso creé un repositorio en GitHub para guardar mi progreso.

A principios de junio de 2020, vi un post en el canal de PHP de Reddit mencionando este proyecto “Phel”: un lenguaje de programación funcional escrito en PHP.

Llevo unos 8 años trabajando con PHP, y siempre intento combinar OOP con FP (creo que ambos paradigmas funcionan mejor juntos; no son excluyentes). Un nuevo dialecto de Lisp escrito en PHP 7.4 nativo sonaba emocionante. Decidí echarle un vistazo al código.

Las lecturas recientes de Mathias NoBack, como Object Design Style Guide y Advanced Web Application Architecture, me dieron el empuje para aplicar lo aprendido en un proyecto real. Este fue (y sigue siendo) un desafío que me ayuda a crecer profesionalmente.

Mi primer commit fue el 6 de junio de 2020. Desde entonces dedico un poco de tiempo cada día en mis horas libres. Me ayuda a aprender sobre FP, diseño interno de lenguajes, testing y arquitectura de software en general.

Empecé con cambios menores hasta que acabé refactorizando toda la estructura del compilador para hacer los módulos más legibles. Psalm, tipos estrictos, buena cobertura de tests, estilo de código unificado… Estos fueron algunos de mis temas favoritos.

Ejemplo de código Phel #

El siguiente ejemplo da una breve impresión de cómo se ve Phel:

# Define un namespace
(ns my\example)
# Define una variable con nombre "my-name" y valor "world"
(def my-name "world")
# Define una función con nombre "print-name" y un argumento
(defn print-name [your-name]
 (print "hello" your-name))
# Llama a la función
(print-name my-name)

Estado actual de Phel #

Preparamos una fácil Guía de Inicio
Preparamos un Repositorio GitHub fácil con una Plantilla de Scaffolding de Phel
Acabamos de lanzar la primera versión oficial: 0.1.0

Consulta el sitio web oficial con toda la documentación: https://phel-lang.org/

También recomendado #

Functional Programming with Phel - JesusValera

Mockear o No Mockear

2021-01-11T00:00:00+00:00

Mockear es útil, pero “qué mockear” suele resultar más complicado de lo esperado si no tratas esto con cuidado.

Cómo escapar del infierno del mocking #

¿Qué pasa realmente cuando creamos un mock? ¿Qué tipos hay? ¿Es bueno o malo mockear? Como siempre, depende del contexto. Aquí veremos las situaciones principales: cuándo mockear, cuándo no hacerlo, y sobre todo por qué.

¿Qué pasa cuando mockeas algo? #

Primero, deberíamos definir qué es un mock:

En un test unitario, los objetos mock pueden simular el comportamiento de objetos reales complejos y por lo tanto son útiles cuando es impracticable o imposible incorporar un objeto real en un test unitario.

Mockear tiene sentido en testing unitario. Un test de integración pasa por la implementación real, verificando cómo interactúan varias unidades. Estos tests sí pueden hablar con la BD o el sistema de archivos. Partimos de esta base: un test unitario es rápido, determinista, no depende de recursos externos y no requiere contexto especial para ejecutarse.

Los mocks cumplen el contrato de la interfaz. Nos permiten testear funcionalidad sin invocar clases colaboradoras complejas.

Un mock es un doble de test que sustituye la implementación real. Además, puede verificar cómo el código bajo test lo utilizó durante la ejecución.

Recomiendo encarecidamente que leas este post si quieres entrar en los detalles de por qué Mockear es un code smell (Temas como estos: ¿Qué es un mock? ¿Qué es un test unitario? ¿Qué es la cobertura de tests? ¿Qué es el acoplamiento fuerte? ¿Qué causa el acoplamiento fuerte? ¿Qué tiene que ver la composición con el mocking? ¿Cómo eliminamos el acoplamiento? ¡y más!)

El problema con mockear #

Cuando mockeas, anulas la lógica de la clase mockeada. La lógica real queda oculta, y ahí es donde los bugs se esconden. Ten en cuenta que:

El mock puede tener atributos, métodos o argumentos que el objeto real no tiene.
Los valores de retorno del mock pueden diferir de los reales. Por ejemplo, puede devolver un tipo distinto con atributos diferentes.
Los efectos secundarios y comportamiento del mock pueden diferir del objeto real. Quizás el mock no lanza una excepción que el objeto real sí lanzaría.

Alternativas a mockear #

“¿Estás diciendo que mockear es malo y no deberíamos mockear?” No.

Depende de lo que estés “anulando”.

¿Es tu lógica de dominio de negocio lo que estás mockeando? Entonces está mal.
¿Es la conexión a la BD lo que estás mockeando? Entonces está bien.

Depende del contexto de la lógica y dónde pertenece esa lógica.

¿Es parte de tu lógica de dominio de negocio? Entonces no deberías mockearla sino instanciarla.

¿Es una dependencia de infraestructura como conexión a BD, sistema de archivos, red, o cualquier servicio externo que no tiene que ver con tu dominio de negocio? Entonces mockéala usando abstracciones/interfaces.

La interfaz es el contrato entre tu lógica de dominio y sus dependencias de infraestructura. Imagina lo fácil que es testear tu dominio instanciándolo y llamando a sus métodos con diferentes argumentos, todo bajo tu control total.

Algunos trucos #

Cuando estés escribiendo un test unitario:

Intenta instanciar tus clases primero.
Evita mockear clases concretas. Escribí un artículo exclusivamente sobre esto: fomentando clases finales e interfaces.

Mockea interfaces. Instancia clases concretas.

“El uso excesivo de mocks lleva a código legacy.” - Philippe Boargau

¿Cómo podemos evitar el mocking excesivo? #

Favorece el estado inmutable sobre el estado mutable.
Haz las dependencias explícitas.
Programa hacia una interfaz, no hacia una implementación.

Referencias #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Nunca Uses array_merge en un Bucle

2020-11-10T00:00:00+00:00

Usar array_merge dentro de un bucle mata el rendimiento. El operador spread te ayudará a mejorar esto aplanando el array.

Aplanando un array de un nivel #

He visto a gente usar array_merge dentro de un bucle así:

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = [];
foreach($lists as $list) {
 $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

Esto es mala práctica porque destroza el rendimiento de memoria. Mejor usa el operador spread (disponible desde PHP 5.6):

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Desempaquetando un array asociativo #

¿Y si tuvieras un array asociativo como este?

<?php
$lists = [
 'key-1' => [1, 2],
 'key-2' => [3, 4],
 'key-3' => [5, 6],
];

En ese caso, necesitarás desempaquetar sus valores:

<?php
$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

En programación funcional, esto se conoce como aplanar una lista. Sin bucles ni problemas de rendimiento.

Aplanando un array multinivel #

¿Y si quisieras aplanar un array multinivel como este?

<?php
$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

¿O como este, incluso con clave-valores?

<?php
$lists = [
 'key-1' => [
 1,
 [2],
 'key-2' => [
 3,
 [
 'key-3' => [4, 5],
 ],
 ],
 ],
 6,
 'key-4' => [7, 8],
];

Para estos casos, puedes usar la librería estándar de PHP:

<?php
$merged = iterator_to_array(
 new RecursiveIteratorIterator(
 new RecursiveArrayIterator($lists)
 ),
 $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Qué enfoque de aplanado usar #

Normalmente, saber aplanar un array de dos niveles suele ser suficiente:

<?php
$flattenList = array_merge(...array_values($lists));

Para casos más complejos, la librería estándar de PHP te saca del apuro.

Referencias #

Arrays Tipados en PHP

2020-10-13T00:00:00+00:00

Desempaquetado de argumentos, lista de argumentos variables de función, y funciones variádicas.

La combinación perfecta #

Desempaquetado de argumentos: pasa los elementos de un array como argumentos individuales a una función.
Lista de argumentos variables: la función recibe los argumentos como un array.
Función variádica: permite verificar los tipos con un type-hint.

Usaremos este snippet para nuestros ejemplos. Tenemos una clase Customer:

<?php
/**
 * @psalm-immutable
 */
final class Customer
{
 // Usando la promoción de propiedades en constructor de PHP 8
 // https://wiki.php.net/rfc/constructor_promotion
 public function __construct(
 public string $name,
 ) {}
}
// Creamos una lista de 6 clientes
$customers = array_map(
 fn(int $i): Customer => new Customer("name-{$i}"),
 range(1, 6)
);

Siempre que queramos manipular una lista de Customers, podemos pasar como argumento: …$customers.

Cómo solíamos hacerlo #

Definimos el tipo del array con PHPDoc, pero no podemos forzar el tipo real de cada elemento. El código se ejecuta sin problemas aunque pases cualquier tipo en array $customers:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 // ... alguna lógica irrelevante para este ejemplo
 }
}

El código de abajo funcionaría en “tiempo de compilación”. Pero podría fallar en “tiempo de ejecución”.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]);

Una alternativa recomendada: extraer la lógica y pedir el tipo concreto para verificarlo en tiempo de ejecución. Fallará si alguno de los elementos no es un Customer:

<?php
/**
 * @param Customer[]
 */
function createInvoiceForCustomers(array $customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}
function createInvoice(Customer $customer): void
{
 // ... alguna lógica irrelevante para este ejemplo
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice(Customer $customer) recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers($customers);
createInvoiceForCustomers([new Customer('any name')]);
createInvoiceForCustomers([new AnyOtherType()]); // no funcionará

Con createInvoice(Customer $customer) aseguramos el tipo del argumento. Pero, ¿podemos ir un paso más allá? ¿Podríamos verificar los tipos al llamar a createInvoiceForCustomers(array $customers), y que el IDE se queje si los tipos no son correctos?

Eso es precisamente para lo que sirven los Generics, pero aún no existen en PHP. Ni siquiera en PHP 8. Quizás lleguen pronto, pero por ahora hay una alternativa menos conocida con sus pros y contras. Veamos un ejemplo:

<?php
function createInvoiceForCustomers(Customer ...$customers): void
{
 foreach ($customers as $customer) {
 createInvoice($customer);
 }
}

Todo lo de aquí abajo funcionaría en “tiempo de compilación”. Seguro que fallará durante “tiempo de ejecución” si createInvoice() recibe algo diferente a un Customer.

<?php
createInvoiceForCustomers(...$customers); // OK
createInvoiceForCustomers(
 new Customer('any name'),
 new Customer('any name'),
); // OK
// Esto ni siquiera es posible de escribir. El IDE te gritará.
// Está esperando un `Customer`, pero `AnyOtherType` es dado:
createInvoiceForCustomers(new AnyOtherType());

PROS #

Podemos tipar una lista de cualquier tipo concreto de forma sencilla.

CONTRAS #

Mejor limitar las funciones a uno o dos argumentos. De lo contrario, se complica la lectura.

Observaciones importantes #

Debe ser el último argumento de la función.
Ayuda a minimizar el número de argumentos.

Los variadics simulan arrays tipados, úsalos con cabeza #

El desempaquetado de argumentos, combinado con funciones variádicas, nos permite simular arrays tipados. Un gran poder conlleva una gran responsabilidad. Hay que conocer bien nuestras herramientas para usarlas con criterio.

Referencias #

Guía de estilo para diseño de objetos

2020-10-10T00:00:00+00:00

Los objetos son el corazón de lenguajes como Java, Python y C#. Si aplicas buenas prácticas de diseño, tu código será más fácil de leer, escribir y mantener.

Este libro reúne docenas de técnicas para crear código OO profesional que aguanta el paso del tiempo.

Los ejemplos usan pseudocódigo fácil de entender. Las técnicas aplican a cualquier lenguaje OO, desde C++ hasta PHP.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

Este libro te ayuda a poner en forma tus aplicaciones web. Trae muchas técnicas para desacoplar tu código de la infraestructura (el framework, la base de datos, etc.).

La Parte 1 presenta patrones de diseño para separar código de negocio e infraestructura. La Parte 2 muestra cómo estos patrones encajan con conceptos arquitectónicos como capas, puertos y adaptadores (arquitectura Hexagonal). El libro cierra con estrategias de testing y decisiones de diseño.

Lo que aprenderás #

Separar código mezclado en código de negocio e infraestructura usando patrones.
Dividir tu código en capas con una distinción clara entre puertos y adaptadores.
Testear aplicaciones desacopladas.

Compra el libro: https://leanpub.com/web-application-architecture

Patrones de diseño para modernizar código legacy #

Strict Types en PHP

2020-08-09T00:00:00+00:00

En diciembre de 2015, PHP 7 introdujo las declaraciones de tipos escalares y la bandera strict types. ¿Qué es esto?

Lo bueno de declarar un archivo PHP como estricto es que se aplica solo al archivo actual. Asegura tipos estrictos en ese archivo, pero no afecta al resto del proyecto. Puedes migrar de código no estricto a estricto paso a paso, especialmente en archivos o proyectos nuevos.

Para habilitar el modo estricto, coloca una directiva declare al principio del archivo. La estrictez de tipado para escalares se configura por archivo. Esta directiva afecta tanto a los parámetros como al tipo de retorno de las funciones.

Strict types afecta la coerción de tipos #

Usar type hints sin strict_types puede causar bugs sutiles.

Sin strict types, int $x significa “$x debe ser coercionable a int”. Cualquier valor coercionable a int pasaría:

un int (42 -> 42)
un float (13.1459 -> 13)
un bool (true -> 1)
un null (null -> 0)
un string con dígitos al inicio (“15 Trees” -> 15)

Con strict_types=1, le dices al motor que int $x significa que $x debe ser un int real, sin coerción. Tienes la seguridad de que recibes exactamente lo que se pasó, sin conversiones ni pérdida de datos.

¿A quién le importa esta línea? #

declare(strict_types=1); es más para el lector que para el escritor. Le dice explícitamente:

Los tipos en este archivo se tratan de forma estricta.

‘strict_types=1’ es más para el lector que para el escritor

El escritor solo necesita mantener esa estrictez mientras escribe. Pero como escritor, deberías preocuparte por tus lectores. Eso incluye a tu yo futuro.

Referencias #

Clases Final en PHP | Java | Cualquiera

2020-06-06T00:00:00+00:00

Contratos claros, efectos secundarios aislados, testeabilidad, baja complejidad y carga cognitiva, fluidez del código y confianza en ti mismo.

Motivación #

Reduce la visibilidad al mínimo #

Cuando una clase es final, no puede ser extendida. Esto la hace más legible y te asegura que la lógica está limitada a esa clase.

Fomenta “composición sobre herencia” #

El Principio Abierto-Cerrado dice: abierto para extensión, cerrado para modificación.

Si decides crear una herencia (por una buena razón, de la que deberías ser consciente), simplemente quita final y listo.

Cuando por defecto no puedes extender una clase, te fuerzas a pensar en composición en lugar de herencia.

¿Por qué esta clase no es final? #

Si preferimos composición sobre herencia, deberíamos evitar la herencia tanto como sea posible. La herencia se usa mal a menudo en POO.

Un concepto mal entendido #

Cuando nos enseñaron POO, normalmente empezamos con el ejemplo clásico de herencia.

Pero cuando Alan Kay creó Smalltalk, la herencia no era el concepto principal. Lo principal era el paso de mensajes: enviar mensajes a objetos que encapsulan datos y lógica, cambiando comportamiento mediante diferentes objetos. Eso es composición. La herencia se hizo tan popular que terminó eclipsando a la composición.

Beneficios #

Contratos claros. Usar interfaces te obliga a pensar en comunicación entre objetos.
Código aislado, sin efectos secundarios. Inyectar solo interfaces elimina efectos secundarios molestos.
Testeabilidad. Mockear interfaces es muy fácil.
Complejidad manejable. Todo aislado significa menos cambios en cascada.
Baja carga cognitiva. Menos complejidad, más foco en lo importante.
Flexibilidad. Sin acoplamiento innecesario, mover código es más fácil.
Confianza. Testear código aislado te da seguridad para cambiarlo.

Composición sobre herencia #

Si necesitas reconfigurar un objeto, cambiar partes de un algoritmo o reescribir parte de la implementación, considera crear una nueva clase en lugar de sobreescribir una existente.

¿Necesitas representar una jerarquía donde las subclases sustituyen a las clases padre? Esta sería la situación clásica donde podrías usar herencia. Aun así, el resultado suele ser mejor si heredas de interfaces abstractas, no de clases concretas.

Qué hacer en su lugar #

Usa interfaces para definir contratos entre clases.
Usa clases finales para implementar esas interfaces.
Usa composición (inyección de dependencias por constructor) para unir las piezas.

Interfaces -> Clases finales -> Composición

Symfony 5

2020-02-20T00:00:00+00:00

Escrito por el creador de Symfony, este libro presenta un enfoque práctico para desarrollar aplicaciones web con Symfony 5: desde cero hasta producción. Si estás descubriendo Symfony por primera vez o quieres refrescar tus conocimientos, esta guía te da una introducción completa a las aplicaciones modernas con Symfony.