Clases, Objetos y Estructuras de Datos

Es muy comun hoy en dia trabajar con lenguajes fuertemente centrados en la programacion orientada a objetos, como Java, C# o TypeScript.

Con esto en mente, resulta importante definir ciertas reglas y convenciones para trabajar con clases, objetos y estructuras de datos. Dentro de los principios mas importante que nos interesa destacar en mindsight, encontramos los siguientes.

Encapsulacion

Los detalles internos de una clase u objeto no deben estar expuestos para el resto del mundo. Solamente las interfaces bien definidas deben poder ser accesibles desde el exterior. Esto reduce las dependencias y facilita el mantenimiento del codigo, permitiendo que las modificaciones internas del objeto no tengan repercusiones en el resto del sistema.

Prioriza estructuras de datos mas que objetos

La idea dentro de la programacion de que todo es un objeto es un mito. Muchas veces lo que se requiere es una estructura de datos simple, y no un objeto con metodos y propiedades.

La diferencia vital entre un objeto y una estructura de datos es que los objetos encapsulan datos y exponen funciones, mientras que las estructuras de datos exponen datos y no funciones. Basicamente, ambas son opuestos que se complementan. A esto se le conoce como “Anti-simetria entre Objetos y Datos”.

Con estructuras de datos, se puede tomar un enfoque procedural, mientras que con objetos se toma un enfoque orientado a objetos. El enfoque procedural hace que sea mas simple añadir nuevas funciones sin tener que modificar las estructuras de datos, mientras que el enfoque orientado a objetos hace que sea mas simple añadir nuevos tipos de datos sin tener que modificar las funciones.

En el desarrollo de software, el escenario mas comun es querer añadir nuevas funcionalidades, lo cual hace preferible añadir nueva estructuras de datos, con procedimientos que operen sobre ellas.

Evita las estructuras hibridas

Las estructuras hibridas son aquellas que mezclan estructuras de datos y con funciones de mala manera. Estas estructuras mezclan funciones altamente significativas (como los objetos) con propiedades publicas o accesibles mediante metodos, lo cual permite operar sobre estos de la manera en la que un programa procedural lo haria sobre una estructura de datos.

Estos hibridos hacen que sea dificil añadir nuevas funciones y al mismo tiempo hacen dificil añadir nuevos tipos de datos, trayendo consigo lo peor de ambos mundos.

Responsabilidad unica

Este principio hace enfasis en que una clase, estructura de datos u objeto deberia limitarse a implementar un unico concepto o comportamiento. Clases mas pequeñas son mas faciles de entender, testear y mantener.

Limita las variables de las instancias

Una clase deberia limitar el numero de variables de instancia que tiene, o en palabras mas simples, hay que reducir el numero de atributos que tiene una clase.

Clases padre e hijas

Las clases padres deberian ser independientes de las clases hijas, osea que no deberia conocer a sus clases hijas. Esto nos asegura que las clases hijas puedan ser modificadas sin afectar a las clases padre.

Esto tiene amplia relacion con el principio de sustitucion de Liskov, que establece que instancias de clases hijas deberian poder sustituir a instancias de su clase padre sin afectar el comportamiento del programa. Mas informacion sobre este principio en la seccion de SOLID.

Prefiere multiples funciones sobre seleccion de funcionalidad

En lugar de tener una funcion que seleccione una funcionalidad basada en un flag, es preferible tener multiples funciones que hagan una sola cosa. Esto hace que el codigo sea mas facil de entender y de mantener.