FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar?
Cita:
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, |
#2
|
||||
|
||||
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.....
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
||||
|
||||
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 |
#4
|
|||
|
|||
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.
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#5
|
||||
|
||||
Cita:
Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#6
|
||||
|
||||
Programación atómica
¡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. |
#7
|
||||
|
||||
Cita:
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. |
#8
|
||||
|
||||
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 |
#9
|
||||
|
||||
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 |
#10
|
||||
|
||||
Cita:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#11
|
||||
|
||||
Cita:
A -> B -> C -> D ->.... ...y fue Delphius quien la comentó... (raise TIncorrectQuote.Create('Se equivoicó de persona')
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#12
|
||||
|
||||
Cita:
Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#13
|
|||||
|
|||||
Cita:
Un iniciado, por conseguir una buena modularidad empieza a repartir las funciones en módulos... y llega a cosas como: A -> B -> C -> D -> E ->.... Es correcto lo que hace... pero uno llega a preguntarse: ¿Hasta que punto sería fiable? Hay métricas que determinan un valor en base al juicio del desarrollador, pero también existe un "grado de duda" al momento de estar diseñando. No discuto de que sean fiables... de seguro que si. Creo en que lo que realizó Borland es un producto espectacular. Pero... me abruma un poco el hecho de los círculos viciosos que puede formarse por los encadenamiento de las funciones. Totalmente de acuerdo que estos encadenamiento pueden añadir complejidad... pero también reconozco que tiene sus ventajas. Cita:
Si bien son dos palabras diferentes... son dos palabras que vienen mucho de la mano. Si yo he entendido bien el concepto para lograr una gran reusabilidad es necesario contar con un buen grado de modularización. Y a la inversa: una buena modularización permite un mejor uso. No se puede separar ambos conceptos totalmente, hay una línea delgada que los mantiene unido. Y creo que encontrar esa línea delgada es lo más complicado de hallar. Si estoy equivocado, avisenme... porque llevaría años equivocado. Como tu comentas... es cierto que se consigue una modularización innecesaria por hacer uso de las funciones "incorrectas". Pero... volvamos al caso del novato (por ejemplo... yo). Un novato... declara y declara funciones... que ya vienen incorporadas... No se da cuenta de que puede evitar este comportamiento (no por ser ignorante... las buscó pero no bien). Le funciona... Por lo tanto sigue con su trabajo. Obedeciendo su instinto de que desea hacer un buen trabajo separa bien los módulos... y sigue haciendo su trabajo... al estilo del problema del año bisiesto. ¿Lo está haciendo mal? Si y No. Podría hacerlo mejor... si. No es una persona cerrada y empieza a armar un diseño rápido de todos los módulos... saca una cuantas hojas sábanas y arma una linda carta de estructura (por poner un ejemplo) y nota un gran despliegue de módulos. Se pregunta: ¿Hasta que punto conviene llegar? Y vamos.. que esto no sólo se consigue con las funciones "innecesarias", aún con las correctas se puede armar un buen lío. Cita:
Pero también existen herramientas que la ingeniería del software han venido aportando. Hay métricas que permiten ofrecer una medida de lo bien que se tiene modularizado... se sabe que no es un valor rígido y que hay que obedecer pero es buen estimativo. A ver... la pregunta que debí haber formulado sería algo así: De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado? Al, yo también soy partidario a particionar el código. Yo dentro de mi esquema de trabajo impongo esa actividad... pero tal como dicen otros... tampoco hay que decaer en el extremo (que ya me pasado) de partir una función en muchos pedazos que poco o nada hacían por si mismo. Cita:
Cita:
Bueno para finalizar... repito: De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado? Disculpen si el debate no tiene sentido... pero me pareció una buena idea, ver los aportes de grandes de estos foros. Yo lo hacía con el fin de aprender y comparar mi modo de entedimiento de lo que es este mundillo de la ingeniería del software. Saludos, |
#14
|
||||
|
||||
¡Hola a todos!
Cita:
Insisto en que pongamos un ejemplo de función Delphi de más de 20 líneas de código nativo y hagamos el ejercicio de atomizarla. Nos permitiría acercar criterios en esta materia y establecer una norma teórica. Un largo abrazo. Al González. |
#15
|
||||
|
||||
Cita:
Saludos insistentes
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#16
|
||||
|
||||
Hola a todos.
Estoy de acuerdo con seoane y su profesor: Cita:
En conclusión ( y es mi modesta opinión): Cita:
__________________
Cita:
|
#17
|
||||
|
||||
Cita:
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". |
#18
|
||||
|
||||
Cita:
Ahora, estoy completamente de acuerdo con este párrafo tuyo: Cita:
Pero sigo sin entender el sentido de tu duda. Creo que todos tenemos más o menos claro y estamos de acuerdo en ello, en que la modularización promueve el reuso y sólo hay que tener cuidado de no caer en la pulverización de código, tal como sintetiza Al: Cita:
Código:
A->B->C->D-> ... ->A' ¿Es esto culpa de la modularización? ¿Tu duda va en ese sentido? Quizá en algunos caso lo sea, pero eso no es óbice para modularizar, es sólo algo que debe revisarse y evitarse. // Saludos |
#19
|
|||
|
|||
Coincido con todos en general, pero si hablamos como ya lo mencione de los estilos de programar y haciendo uso de lo dicho por Al
Cita:
Cita:
En uno de mis sistemas y que desarrolle su primera versión hace ya algunos años, requiero de calcular la duración desde dos variables de tipo string de fecha y dos variables de tipo string conteniendo la hora. con Delphi 16 bits
con Turbo Delphi
Que pasó, bueno, resulta que mi inexperiencia me dictó en ese momento que así lo tenía que hacer y me bastaba, ahora con TD encontré que todo ese rollo lo podía resolver en una sola línea, yo me imagino que hay algo mejor que eso, pero siendo sinceros me falta mucho para poder optimizarlo. Yo me declaro inconpetente en hablar o discutir eso de atomización, ni siquiera entiendo el concepto aún, pero vamos, la idea principal que quiero expresar es como determinar lo que Delphius inicia como debate. De acuerdo a tu experiencia, ¿Cuál sería la relación Modularidad/Complejidad que se estaría dispuesto a tolerar? ¿Qué criterios usas para determinar que tu trabajo está altamente integrado? Mi sentido común me dice Tolerancia CERO entre Modularidad y Complejidad, mi experiencia (o mi inexperiencia) no puedo medirla, eso es lo que hoy se, el día de mañana y sobre todo aqui en el club me dira otra cosa. Salud OS.
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#20
|
||||
|
||||
Yo creo que la atomizacion del código simplifica en mucho el mantenimiento poterior ya que a todos nos pasa que despues de cierto tiempo se nos olvida un poco como iba el algoritmo sobre el que trabajamos para hacer x cosa. >Con código atomizado podemos llegar a tener cosas como esta:
Código:
Procedure TMiVentana.EjecutaTarea; Begin AbreTablas; PreparaGrillas; If ShowModal=mrOK Then GuardaDatos; CierraTablas; end; Claro que tambien depende del estilo o "convenciones" que usemos en el código ya que si nombramos las funciones con nombres que no vienen al caso pues se pierde la utilidad de la atomización y se complica la cosa. En mis inicios en Pascal acostumbraba usar sintaxis en inglés para casi todo, posteriormente empece a revolver inglés con español y ahora solo uso español. A veces ponia nombres como "SeekFileNombres" o "BuscarFiles"...ahora me dan risa. Otra práctica que de repente uso es la de hacer todo sucio y rápido y luego irlo partiendo, asi pues llego a tener funciones muy grandes que luego voy dividiendo y optimizando, asi por lo menos mis aplicaciones funcionan a a primera y las voy mejorando..
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Programas que calculan la complejidad operacional | Delphius | Varios | 5 | 19-01-2007 10:34:34 |
cual seria el componente correcto? | DM2005 | Varios | 0 | 04-07-2006 21:55:39 |
Cual seria lo ideal? | Coco_jac | Gráficos | 1 | 10-06-2005 01:38:42 |
Cual seria el equivalente de AllTrim (clipper) | Alfredo | OOP | 2 | 04-03-2005 15:58:44 |
cual seria la mas adecuado base de datos... | ronimaxh | Firebird e Interbase | 8 | 23-04-2004 17:47:15 |
|