El paradigma OO vino para quedarse
El pensamiento estructurado dio un paso más y giró sus conceptos para traerle más vida y hacerles el trabajo de forma más fácil y hasta me animaría a decir... humana y realista a los desarrolladores. Y eso fue en la década del 70 cuando empezó a surgir los conceptos del paradigma OO, desde los años 90 que la POO reina, y posiblemente lo reine por siempre.
Si empleas records para mantener la información eso te llevará a trabajar con mecanismos de control y paso de parámetros de estos tipos... a trabajar con la vieja escuela. Esta forma de trabajar lleva a que al menos entre el 25% y el 50% de tus módulos lleven a un Acoplamiento Estampado, de Control o hasta incluso llegar al Acoplamiento por Contenido o Patológico afectando enormemente a la cohesión en general.
Sólo en un proyecto chico y medio básico o elemental propondría "bajar de nivel" y moverme por el pensamiento puramente estructurado.
Ahora bien, puedes hacer algo salomónico... como a lo que yo hago. Mis módulos o unidades bases están orientadas a la vieja escuela y ofrecen una estructura básica que da soporte (tanto los tipos como las operaciones) a las unidades o módulos superiores que están enfocados al pensamiento POO.
Un principal motivo de porqué lo hago de esta manera: claridad entre cohesión y acoplamiento y una manera de separar lo que es una estructura pura y estática de lo que es una clase que por lo general tiene más flexibilidad y está asociada con una característica de "viva".
Por ejemplo, pensemos en una matriz. ¿Que sería lo más adecuado para implementar operaciones sobre estas estructura de datos?
Podría realizar una clase TMatrix que contenga métodos como Traspose(), Trace(), Multiply(), IsIdentity() y otros más de interés. Y dentro de ésta mantener en memoria la propia matriz de toda la vida:
type
TEMatrix = array of TVector;
Al principio yo estuve pensando que podría ser muy interesante llevarlo así pero luego sentí que estaba mezclando demasiado el pensamiento estructurado con el OO y no lo veía como algo bueno. Otra cosa que me evitó seguir este enfoque es que luego veería en mi código cosas como:
Y me llevaría escenarios confusos... ¿Donde meto el resultado de esa operación? ¿En la clase que invoca el método, en la que paso como parámetro? ¿O no será mejor esto?
Y que sea Res el objeto que mantenga el resultado de la operación.
Esto no es bueno, porque incluso me llevaría a una mezcla de cohesión y acoplamiento entre otras estructuras, como un TVector. Hay operaciones que se realizan en conjunto y en doble sentido, entre vectores y matrices....
Implementar estos métodos y basarlo en clases me llevaría a que de algún modo internamente cada clase debiera conocer algunos detalles internos, y de bajo nivel, de la otra para que se pueda realizar las operaciones.
Todo eso me dijo que no era nada saludable. Conclusión: dejar a la estructuras de datos primitivas tal como son y no pensarlas como si fuera una clase. Luego las clases se limitan a abstraer las cosas desde otra perspectivas y controlar el estado general de los datos y dejan el trabajo "sucio" a quien lo hace mejor. No fue fácil descubrir el nuevo contexto de las clases, pero a la larga ahora me resultó mejor.
Saludos,