Ir al contenido principal

El Principio de Responsabilidad Única

 

Responsabilidad Única

El Principio de Responsabilidad Única (Single Responsibility Principle, SRP) establece que una clase debe tener una única responsabilidad y que esta responsabilidad debe estar encapsulada en esa clase. En otras palabras, una clase debe tener un único motivo para cambiar.

 

La idea detrás del principio de responsabilidad Única es mantener el código limpio y modular, evitando que una clase tenga múltiples responsabilidades que puedan generar acoplamiento innecesario y dificultar el mantenimiento y la reutilización del código. Al adherirse a este principio, se busca mejorar la cohesión de las clases, donde cada una se centra en una tarea específica y bien definida.

El siguiente ejemplo NO aplica el principio de responsabilidad Única:


El siguiente ejemplo SI aplica el principio de responsabilidad Única:



 


 

 

Comentarios

Entradas populares de este blog

De Coverlet a JaCoCo: Trayendo la magia de la cobertura a Android Studio

Todo comenzó un día cualquiera, mientras revisaba un reporte de cobertura de pruebas generado por Coverlet para un proyecto en .NET. Me quedé fascinado por el nivel de detalle y claridad que proporcionaba: saber exactamente qué partes del código estaban cubiertas por las pruebas, y cuáles no. Fue entonces cuando me pregunté: ¿Y si pudiera tener algo así en mi proyecto de Android con Kotlin y Jetpack Compose? La Chispa Inicial ✨ Como desarrollador, siempre busco mejorar la calidad de mi código, y contar con herramientas que me permitan medir la cobertura de pruebas es clave. Después de una rápida búsqueda, me topé con **JaCoCo**, una herramienta muy popular para medir cobertura de código en proyectos Java y Kotlin. ¡Lo mejor de todo es que es compatible con Android Studio! Mi objetivo estaba claro: debía integrar JaCoCo en mi proyecto de Android para tener reportes detallados de cobertura, tal como lo había visto en Coverlet. El Desafío: Configurar JaCoCo en un Proyecto Android 🛠️ El p...

Inyección de Dependencias usando Hilt

Inyección de Dependencias usando Hilt La Inyección de Dependencias (DI) es fundamental para construir aplicaciones Android robustas, escalables y fáciles de testear. Mientras que existen varias librerías para lograrlo, Hilt se ha establecido como la solución recomendada y estándar de Google. Construido sobre la potencia de Dagger, Hilt simplifica enormemente la implementación de DI en Android. Si buscas una forma estandarizada, con menos boilerplate que Dagger puro y con excelente integración con los componentes de Android Jetpack, Hilt es la respuesta. ¡Descubramos cómo funciona! ¿Por qué elegir Hilt? Hilt ofrece ventajas significativas para el desarrollo Android: Estándar de Android: Es la librería DI recomendada por Google, lo que asegura buena documentación, soporte y alineación con las prácticas modernas de Android. Menos Boilerplate (vs. Dagger): Reduce drásticamente el código de configuración necesario en comparación con usar Dagger directamente en Andr...

Usando Retrofit para Consumir API

Usando Retrofit para Consumir API La comunicación con servicios web y APIs REST es fundamental en el desarrollo Android. Retrofit simplifica las llamadas de red, Coroutines manejan la asincronía, y un patrón Repositorio/ViewModel estructura el acceso a datos y la lógica de negocio. Para la UI, Jetpack Compose ofrece un enfoque moderno y declarativo para construir interfaces de usuario nativas con Kotlin. En este post, construiremos una app que muestra la lista de repositorios públicos del usuario de GitHub enelramon . Utilizaremos Retrofit para la llamada a la API, un Repositorio para abstraer la fuente de datos, un ViewModel con StateFlow para gestionar el estado, y Jetpack Compose para dibujar la interfaz de usuario de forma reactiva. ¿Por qué Retrofit, Repositorio, ViewModel y Jetpack Compose? Retrofit: Simplifica las llamadas HTTP, maneja la conversión de JSON y se integra perfectamente con Coroutines. Repositorio: Abstrae la fuente de datos (red). M...