Programación orientada a objetos mal aplicada
Errores comunes de POO que veo todos los días
Programación Orientada a Objetos mal aplicada: errores que veo todos los días
La Programación Orientada a Objetos no es mala.
El problema es cómo la usamos.
Después de años trabajando en backend, revisando código de otros equipos y metiéndome en sistemas que llevan años en producción, he visto los mismos errores una y otra vez.
Y casi siempre vienen de entender POO como teoría, no como diseño.
Vamos a hablar claro.
Error #1: Clases que hacen de todo
Este es el clásico.
Clases gigantes que:
- validan
- llaman a la base de datos
- procesan lógica
- envían emails
- escriben logs
- rezan el Padre Nuestro
Todo en una sola clase.
Esto rompe la idea más básica de POO:
una clase = una responsabilidad clara
Cuando una clase hace de todo:
- es difícil de probar
- da miedo tocarla
- cualquier cambio rompe algo
Si una clase te da miedo abrirla… ya sabes que algo anda mal.
Error #2: Pensar que más clases = mejor diseño
Hay gente que descubre Clean Architecture y de momento el proyecto tiene:
- 200 interfaces
- 300 carpetas
- nombres larguísimos
- cero claridad
POO no es crear clases por crear clases.
Un buen diseño:
- se entiende rápido
- tiene pocas piezas
- cada pieza tiene sentido
Si necesitas un mapa para entender tu propio proyecto… estás overengineering.
Error #3: Herencia para todo
Herencia es uno de los conceptos más abusados.
Ejemplo típico:
BaseServiceBaseServiceV2AdvancedBaseServiceUltraAdvancedBaseService
Esto crea:
- jerarquías frágiles
- dependencias invisibles
- bugs difíciles de rastrear
Hoy en día, composición > herencia en la mayoría de los casos.
Pregunta clave:
¿Realmente esto es un tipo de aquello, o solo usa aquello?
Error #4: Objetos sin comportamiento (solo data)
Este es bien común en backend.
Clases que solo tienen:
- propiedades
- getters
- setters
Y toda la lógica vive en servicios gigantes.
Eso no es POO. Eso es programación procedural disfrazada.
Un objeto debería:
- conocer sus reglas
- proteger su estado
- validar su propia consistencia
Si tus objetos no hacen nada… algo está mal.
Error #5: Acoplar todo a frameworks
Este duele 😅
Clases que dependen directamente de:
- Entity Framework
- librerías externas
- infraestructura
Cuando mezclas:
- dominio
- infraestructura
- framework
pierdes:
- testabilidad
- flexibilidad
- control del diseño
POO bien aplicada protege tu dominio, no lo expone.
El problema no es POO, es cómo pensamos
La mayoría de estos errores no vienen de mala intención.
Vienen de:
- copiar ejemplos
- seguir tutoriales sin contexto
- aplicar patrones sin entender el problema
POO no es memorizar conceptos. Es tomar decisiones conscientes.
Una regla simple que ayuda mucho
Antes de crear una clase, pregúntate:
- ¿qué responsabilidad tiene?
- ¿qué NO debería hacer?
- ¿quién la usa?
- ¿qué pasaría si mañana cambia?
Si no puedes responder eso… espera.
Terminando…
POO bien aplicada:
- hace el código más claro
- facilita los cambios
- reduce bugs
- hace feliz al equipo 😄
Mal aplicada:
- crea monstruos
- frena el desarrollo
- quema ingenieros
En los próximos blogs voy a entrar en:
- ejemplos reales en C#
- cómo diseñar objetos útiles
- cuándo NO usar POO
Esto apenas empieza.
Seguimos 👊