Escribir CSS limpio y escalable no es solo cuestión de estética: aplicar principios de ingeniería de software al código de estilos marca la diferencia entre un proyecto mantenible y uno que se vuelve incontrolable. Los principios SOLID, DRY e immutability ofrecen un marco sólido para organizar hojas de estilo de forma profesional, y aquí se explica cómo funciona cada uno con ejemplos concretos.
¿Qué significa cada letra de SOLID en el contexto de CSS?
SOLID es un acrónimo que agrupa cinco principios de diseño orientados a escribir código robusto. Aunque nacieron en la programación orientada a objetos, su lógica se traslada perfectamente al mundo de los estilos.
¿Cómo aplicar el Single Responsibility Principle a las clases CSS?
La S representa el Single Responsibility Principle: una clase debe tener solamente una razón para cambiar [0:14]. En CSS esto se traduce en crear clases con una sola responsabilidad. Por ejemplo, una clase .button que solo define border-radius: 2rem y otra clase .button--secondary que maneja exclusivamente background-color y color. En el HTML se combinan ambas: class="button button--secondary". Cada clase es independiente y cumple una única función.
¿Qué implica el Open Close Principle en los estilos?
La O corresponde al Open Close Principle: las entidades deben estar abiertas para extensión, pero cerradas para modificación [1:15]. Lo incorrecto sería tener una clase .button--secondary que hereda de otra clase ajena (por ejemplo, una de tamaño) y la modifica internamente. Lo correcto es que .button--secondary pueda extenderse con nuevas propiedades sin alterar la clase base.
¿Cómo funciona Liskov Substitution en CSS?
La L se refiere a Liskov Substitution: un subobjeto puede reemplazar al objeto padre sin romper el programa [2:02]. En CSS, .button--secondary sí puede heredar de .button cuando esta última es una clase general que define, por ejemplo, border-radius para todos los botones. Al usar class="button button--secondary" en el HTML, la sustitución funciona sin conflictos.
¿Por qué evitar la sobreescritura según Interface Segregation?
La I representa Interface Segregation: no se debe obligar a ningún código a depender de métodos que no utiliza [2:40]. Si .button--secondary hereda de .button pero luego sobreescribe border-radius con otro valor, estamos violando este principio. Heredar para después pisar propiedades genera inconsistencias que las metodologías CSS buscan prevenir.
¿Qué dice Dependency Inversion sobre los selectores anidados?
La D habla de Dependency Inversion: los módulos de alto nivel no deben depender de módulos de bajo nivel; ambos deben depender de abstracciones [3:14]. En CSS, el error típico es crear cadenas de selectores anidados como .card div .titulo { font-size: ... }. Esto genera problemas de especificidad y acopla elementos hijos al padre. La solución es asignar una clase propia como .text-md con su font-size específico y usarla directamente en el HTML.
¿Cómo evitar repetir código con DRY e immutability?
El principio DRY (Don't Repeat Yourself) invita a no repetir código [4:14]. Un caso frecuente: tener display: flex, justify-content: center y align-items: center duplicados en .card y en un div interno. Lo ideal es crear una clase reutilizable como .center con esas propiedades compartidas, y luego cada elemento solo añade lo que le es propio: border, width, height o padding. Con preprocesadores como SASS se puede usar @extend; sin ellos, basta con combinar clases en el HTML: class="card center".
Por otro lado, immutability establece que un objeto no puede ser modificado una vez creado [5:24]. En CSS, el problema aparece cuando se define un color para .card p y luego se sobreescribe con la clase .gray del mismo párrafo. Esta doble definición genera conflictos de especificidad. La solución es definir estilos de forma clara y única desde el inicio, sin pisar valores previamente asignados.
- Cada clase debe tener una sola responsabilidad.
- Las clases base deben poder extenderse sin ser modificadas.
- Evitar cadenas de selectores anidados que generan dependencias.
- Centralizar propiedades repetidas en clases reutilizables.
- No sobreescribir valores ya asignados en clases heredadas.
Estos principios sientan las bases para trabajar con metodologías como BEM, que permiten estructurar CSS de forma predecible y mantenible. Comparte en los comentarios si ya aplicabas alguno de estos principios o si descubriste prácticas que necesitas corregir en tus proyectos.
