Java: POO y SOLID con un checkout que permite cambiar políticas
Separa reglas, contratos y persistencia. Sustituye un descuento sin modificar el caso de uso y comprueba el contrato con Java 17.
Luis Tavarez ·
Un cambio de negocio pequeño
Un checkout empieza con una regla de descuento. Si cada promoción obliga a editar una clase que también valida y guarda órdenes, el cambio afecta responsabilidades distintas. El objetivo de este ejercicio es poder intercambiar esa regla sin copiar el flujo de compra.
La decisión de diseño
Order conserva los datos y sus invariantes. Discount representa una política; OrderWriter es un puerto de escritura. Checkout recibe ambos por constructor. InMemoryOrders es un adaptador para el ejercicio, no una base de datos.
La separación ilustra responsabilidad única, extensión mediante políticas e inversión de dependencias. El contrato de Discount exige un resultado entre cero y el total original. La sustitución solo es válida si cada implementación respeta ese contrato; implementar una interfaz por sí solo no demuestra Liskov. No hace falta crear una interfaz para cada clase.
Qué ejecutar y observar
El ejemplo comprueba una compra sin descuento, una promoción del diez por ciento y una política inválida. Esta última se rechaza antes de guardar. Usa centavos enteros para este caso; el redondeo comercial, los impuestos y distintas monedas requieren reglas explícitas.
Cuándo adaptar la propuesta
El puerto permite añadir un adaptador SQL sin cambiar el checkout, pero todavía debes decidir los límites transaccionales. Guardar y cobrar externamente no se vuelven atómicos por usar inyección de dependencias. No hay cobros reales ni persistencia en este ejemplo.