Ir al contenido principal

Entradas

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Entradas recientes

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Directorio de descargas

🖥️ Directorio de Software Antiguo y Versiones Anteriores Esta entrada está destinada a ser un directorio de enlaces a software gratuito y versiones antiguas de herramientas populares que pueden ser difíciles de encontrar en la web oficial. 🌐 Importante Todos los programas acá enlazados son gratuitos o han sido liberados por sus desarrolladores. No se incluye software de pago ni versiones ilegales. 💾 Versiones Antiguas de Visual Studio Si necesitás una versión específica de Visual Studio para trabajar con proyectos antiguos, acá dejo algunas opciones: Descarga Visual Studio 2010 (ISO y service pack) Visual Studio 2010 Service Pack 1 (SP1) Descarga Visual Studio 2019 Community (instalador) Visual Studio 2019 Descarga de Office Home Student 2019 Retail (ISO) Office Home Student 2019 Retail Para más versiones, también podés visitar la página oficial de Microsoft Visual Studio Older Versions  (pide login). Aunque Microsoft tiende a aplicar algunas limitaciones a veces al usuario y lu...

Guía Completa para Crear un README.md Profesional en GitHub

¿Qué es un README.md y por qué es importante? El archivo README.md es la primera impresión que un desarrollador obtiene al visitar un repositorio en GitHub que hayas creado. Sirve como documentación principal de un proyecto, proporcionando información sobre su propósito, estructura y uso. Un README.md bien elaborado puede mejorar la comprensión del proyecto, facilitar la colaboración y también atraer contribuyentes. Estructura recomendada de un README.md Una estructura comúnmente utilizada para hacer que tu README.md sea claro, informativo y atractivo: 1. Título y Descripción El título debe ser claro y descriptivo. Pensalo también, como un término de búsqueda que alguien podría buscar en Google. Luego, una breve explicación del proyecto: # Nombre del Proyecto Una breve descripción sobre qué hace tu proyecto. 2. Insignias (Badges) Podés agregar insignias para indicar el estado del build, cobertura de pruebas, licencias, entre otros: !...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...
Buy Me A Coffee