¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?

[[Delphius]]

Todos los caminos conducen a roma

He seguido al hilo saber si un año es biciesto... y se me vino a la mente una pregunta... ¿Hasta que nivel de ramificaciones se estaría dispuesto a llegar para hacer una funcionalidad?
He notado como estas funciones y muchas otras... hacen llamadas tras llamadas... y más llamadas...
Veamos:
A -> B -> C -> D ->....

Si bien ya se ha respondido a la duda de JM75... y se he encontrado al culpable (IsLeapYear). Mi duda va por una cuestión de diseño: ¿Hasta que nivel estarían disupesto a declarar unidades y funciones para "simplificar la vida"?

La VCL está llena de ejemplos de estos tipos... me parece bárbaro que haya cantidad y variedad de funciones para hacer más fácil la vida de un programador. Pero me abruma un poco la cantidad de volteretas que se puede armar... en especial cuando uno se inicia, porque empieza a declarar funciones a lo loco y después descubre que si existían... a mi me sigue pasando...

¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?

No se si se hacen estas preguntas o el loco soy yo... A ver que opinan, escucho opiniones, sugerencias...

Saludos,

[Neftali [Germán.Estévez]]

Bueno, yo en esta cuestión soy bastante "básico"; Si ya se ha "inventado la rueda" y la fuente del invento es fiable, no hay porqué reinventarla.
Considero el código de Borland como muy fiable; Puede ser que haya alguna función que no esté optimizada al máximo, pero seguro que el 98% del código puede ser tan fiable y eficiente que el que pueda hacer yo.

La experiencia me dice que los "cuellos" de botella de una aplicación (al menos por las que yo me muevo) no "suelen" estar en una función como IsLeapYear (por muy ineficiente que sea), sino en sitios muy diferentes (índices, consultas, listas, busquedas, repintados,...). Así que salvo que sea necesario no suelo "pelearme" a este nivel.
Sí lo he hecho alguna vez (la última con la unit SysUtils y el procedimiento InitializePackage), pero como digo es algo muy excepcional.

Creo que la Modularidad a la larga añade complejidad (en el sentido de llamadas como las que comenta Seoane), pero aporta otras cosas.
Es la discusión de siempre;
Lo más eficiente: Programar en ENSAMBLADOR. ....discutible.....

[roman]

Yo es que no entiendo esta pregunta. Me parece que se están mezclando dos cosas: modularización y reuso.

En el caso del año bisiesto el problema es que se crea una modularización innecesaria debido el reuso incorrecto de funciones.

Y bueno, aunque no se trata de abusar, creo que a hoy en día, unos cuantos elementos más en el stack no presupondrán un grave problema, sobre todo si lo comparamos con la claridad que puede ganarse al modularizar una rutina. Creo que mientras la modularización no devenga en pulverización, no hay problema.

// Saludos

[[egostar]]

Yo también no estoy del todo convencido con este debate y por una simple razón.

Todo depende del tiempo y de las circunstancias, (siempre me ha gustado esta frase ), bueno, quiero decir que depende mucho de quien se este hablando porque no es lo mismo mi estilo de programar (por cierto considero que no lo hago nada bien, pero intento hacerlo) y el estilo de roman o de seoane, neftali, etc que son muy diestros para hacerlo.

Para esto también hay niveles de conceptualización muy personal.

Sin embargo, si puedo decir que lo mejor es lo que dijo Neftali, no tratar de inventar la rueda pero agrego que si podemos intentar mejorarla.

Salud OS.

[[Al González]]

¡Hola a todos!

Soy partidario de la atomización del código, es decir, de dividir rutinas en sus fragmentos funcionales más elementales. Esto maximiza el aprovechamiento del código (reutilización), además de permitir un mantenimiento menos invasivo, más preciso y menos riesgoso (no es lo mismo tomar una simple llave de 3/8 y apretar con ella una tuerca perfectamente accesible e identificada, que ponerse un traje de buzo para bajar a donde está el submarino nuclear, buscar la tuerca floja de su casco, abrir la caja de herramientas...).

Con ciertos lenguajes y compiladores, atomizar el código supone limitaciones importantes. Por ejemplo, algunas versiones de FoxPro no soportan más de cinco niveles de llamadas (una verdadera vacilada). Herramientas como Delphi están más preparadas para eficientar el código y con la nueva característica In-line de las versiones más recientes del compilador, la atomización ya no supone un mayor consumo de recursos en el ejecutable (de por sí, dicho consumo extra casi nunca resultaba significativo).

Considero que en el futuro el estilo de la programación atómica estará altamente difundido y será común encontrar normativas de desarrollo que inviten al programador a no escribir funciones de más de 15 o 20 líneas. Llegará un momento donde las bibliotecas de rutinas y componentes estén tan atomizadas que sus diversas partes podrán acoplarse sin mayores problemas para construir nuevos elementos de software, aún en otros lenguajes y para propósitos muy distintos, y habrá tanto y tan variado y flexible código reutilizable que cualquier rutina nueva que se quiera escribir tendrá gran riqueza de átomos de dónde echar mano.

Se me ocurre que podríamos hacer un ejercicio a este respecto, pongamos aquí el código de una función Delphi con más de 20 líneas y atomicémosla explicando las ventajas del nuevo código resultante. Domingo, tú que eres aficionado a estos ejercicios, ¿tendrás alguna función así para compartir?

Un abrazo optimizado.

Al González.

[[Lepe]]

Empezado por Neftali

pero seguro que el 98% del código puede ser tan fiable y eficiente que el que pueda hacer yo.

No tienes abuela, ¿verdad?

Saludos

[[seoane]]

Empezado por Neftali

Creo que la Modularidad a la larga añade complejidad (en el sentido de llamadas como las que comenta Seoane), pero aporta otras cosas.

Por curiosidad, ¿que llamadas comente?.

Por otro lado, ya que me meto, dejo mi opinion. Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas

Yo personalmente cuando estoy desarrollando un algoritmo complicado encuentro muy útil usar funciones para dividirlo en problemas mas sencillos y poder resolver cada uno por separado.

[[Caral]]

Hola
Yo ni opino.
Nada mas veo y aprendo.
Si no digo algo no me llega por correo.
Cuando los maestros se reunen hay que estar presente.
Saludos

[roman]

Estoy de acuerdo con seoane, el maestro de seoane y también con Al González; pero, como dije antes, no hay tampoco que caer en la pulverización del código y separar en una función cada simple paso de la función original.

// Saludos

[[Lepe]]

Empezado por Caral

Si no digo algo no me llega por correo.

Debajo del boton Responder, en el menú herramientas, tienes la opción "suscribirse a este hilo", pero claro, si lo usas.... no aumentas tu contador de mensajes

Saludos

[Neftali [Germán.Estévez]]

Empezado por seoane

Por curiosidad, ¿que llamadas comente?.

Perdón, me refería a este tipo de llamadas:
A -> B -> C -> D ->....

...y fue Delphius quien la comentó...
(raise TIncorrectQuote.Create('Se equivoicó de persona')

[PabloTech]

Hola a todos.
Estoy de acuerdo con seoane y su profesor:

Empezado por seoane

Yo tenia un profesor que decia que si no puedes ver todas las lineas de una funcion sin usar el scroll es hora de partila en funciones mas pequeñas.

Aunque no soy tan drástico al respecto. Yo también tengo bloques de programa un poco mas extensos que eso. Pero, por lo general, trato de resumir los algoritmos para aclarar mi panorama. A los módulos trato de darles nombres bien significativos. Siempre trato de usar parámetros, pero en poca cantidad. Y casi siempre reviso en forma rápida el código completo.
En conclusión ( y es mi modesta opinión):

Cuanto mayor sea la complejidad del problema, mayor será la modularidad aplicada. De tal forma, que el cociente entre ambas, tienda a uno (1).

chau...

[Ñuño Martínez]

Empezado por Julio Caesar

Divide et vincere

Yo intento aplicar esta máxima en la programación porque, como dice seoane (más o menos) al dividir un problema grande en problemas más pequeños y fáciles de solucionar, el problema grande se hace más fácil de solucionar.

Aun así, cuando programo en C suelo unir esas rutinas pequeñas en una única más grande que después optimizo, pero antes he escrito y comprobado el sistema "atomizado".

[Neftali [Germán.Estévez]]

Empezado por Lepe

No tienes abuela, ¿verdad?

Y si no me lo digo yo ¿Quién me lo va a decir?

[[cHackAll]]

Desde mi punto de vista la relacion tiene que estar directamente proporcional al asunto de costo/beneficio, si queremos hacer algo por lo que nos pagaran bien, tenemos tiempo, nos gusta o es muy importante entonces (yo), analizo 100 veces mas uno la mejor forma de realizar lo necesitado, pero como ya expuse en otros sitios, la forma mas optima a la que llegarás sera solo con assembler, luego de haber comprobado que el código realizado es mejor a los tres anteriores realizados por tamaño y velocidad.

En lo de la rueda, mientras sea yo quien cree la rueda tendre el control que quiera sobre los sistemas que utilicen mi producto... talvez en este momento estas usando algo con un backdoor, o talvez lo hizo un "tapado" y esta hecho al huevo pero funciona! La decision debe ser (como todas) la mejor que se adecue al caso particular!

[[Delphius]]

Empezado por Lepe

Ahhh, que es para tu tesis... Ahora comprendo el por qué de tanta teoría [...] Pues quien sabe, quizás algún día, Delphi integre una opción en el menú Project -> "Detectar esfuerzo" gracias a tí.

No sería tan raro, Borland ya adoptó el VirtualTreeView por ser gratutio con fuentes .

Saludos.

Acabo de ver, una de las tantas presentaciones sobre Delphi 2007 que hay (si recién ahora las estoy viendo... aprovechando banda ancha) cuando me topé con una que trataba sobre calidad. Ustedes saben como me gusta el tema de UML, métricas, y esos bichos raros

No pude evitar recordar este comentario mientras veía el video... y bueno...
¿Porqué c... llego siempre tarde para las ideas?

Hubiera sido lindo que toda esta charla hubiera sido hecha en el 2006 o el 2005... Podría tener una escusa para decirle a Borland/CodeGear: "Hey... la idea fue de Clubdelphi"

Vine al hilo para sacarme la duda de la fecha en que fue tratado todo esto... pero como podran ver... fue posterior al lanzamiento...

Como que se me subió el ego (Dije ego... no Egostar. Hay que aclarar hoy en dia)... sería maravilloso leer en su acerca de: "Idea Original: Delphius"

Bueno resucité el hilo solo para esto.
Son las 4:15 am en Argentina, quiere agarrarme el sueño. A ver... si esta vez me le adelanto, aunque sea en sueños

Saludos,