Los programadores hemos soñado alguna vez con encontrar esa función o esa clase univarsal que nos ayude en nuestro quehacer diario.
Hasta hace unos tres años yo también buscaba ese código mágico que aumentase mi productividad, incluso cree muchos prototipos de funciones y objetos que después tuve que dejar de lado por varias razones:
- Mantenimiento complejo. El código crecía sin parar según le incluia casos con el riesgo de no poder depurar.
- Gran cantidad de parámetros. Llegó un momento en que en vez de pasar unos cuantos parámetros a una función fue incomodísimo, intente hacerlo con un array, pero fue peor el remedio que la enfermedad. Pense que con una clase sería mejor, teniendo una serie de datas fáciles de manipular.... La cosa se puso fea con tato valor que asignar.
- Lentitud. Al pretender que la funcion/clase fuese universal se encontraba con gran catidad de DO CASE e IF que debian ser procesados cada vez. Con la clase quizás podría heredar, la cosa se puso bastante complicada ya que se perdía la idea priginal de universalidad.
Después de llevarme mucho tiempo dandole vueltas a la cabeza buscando una solución caí en la cuenta de una cosa que siempre me había ido bien: dividir el problema en partes más pequeñas. Así que al final aplique la filosofía oriental (creo) y en vez de tener un monton de código aglutinado y controlado por innumerables condiciones cree funciones más pequeñas, más fáciles de mantener y tambien cree clases donde realmente se justificaba su uso, ya que muchas veces nos obcecamos en hacer clases y objetos de cosas que realmente no son necesarias.
La conclusión final es que el programador debe aplicar en cada momento la solución más favorable dependiendo del problema a resolver evitando caer en errores de estandarizar las cosas que no son suceptibles de serlo por el simple hecho de que los procesos son muy parecidos; lo mejor es extraer la parte común a funciones o métodos más pequeños y manejables para que su mantenimiento sea fácil.
Dos consejos que yo uso:
1- Prefiere la composicion a la herencia.
2- Busca lo que varia y encapsulalo.
El problema es que estás perdiendo el tiempo al tratar de reinventar la rueda... hace tiempo que estos problemas ya fueron resueltos.
Busca en Internet información sobre "Patrones de Diseño" y "Principios de Diseño", ambos relacionados con OOP.
Libros, por ejemplo el "GOF" (la banda de los cuatro).
Efectivamente como dice el comentario anterior la solucion es la programacion orienta al objeto...
Hay dos prinipios improtantisimos para el tema que se plantea aqui:
1.- La herencia
2.- La espcializacion
Es eso, si realmente quereis ser muyyy productivos usar las tecnicas que proporciona la OOP sin mas.
Empezar por algo abstracto y llegar a lo mas concreto, y para ello usar el principio de de la herencia y la espeializacion...
Si una clase se vuelve muy gorda e impracticable es que no esta bien diseñada en si misma y dentro de lo que en OOP se llama escenario. Ahi es donde se vera la interrelacion que tienen los objetos entre ellos, ahi es donde se ve como tiene que actuar el sistema en tratar los eventos. Ahi es donde hay que ver que es suseptible de ser una clase y lo que puede ser una "asociacion", por ejemplo: una nomina es la asociacion de dos clases de diferentes: trabajador y puesto de trabajo.
Cuando se quiere hacer un buen diseño hay que tener muy en cuanta esto para no engordar innecesariamente el sistema...
Todo esto podriamos hablar mucho... pero solo quiero deciros que la OOP es lo mejor sin duda alguna.
Mis programas serian tan simples como este codigo:
function main()
local oApp := TApplication():New( "Mi aplicacion" )
oApp:Run()
return( nil )
Y ya esta ;-)
Ahora la oop ha avanzado y no solo hay que quedarse en lo tradicional, y si no que es OLE (COM) o los JavaBeans (CORBA)?
Efectivamente objetos binarios usables desde cualquier lenguaje que sepa interpretar esas tecnologias...
Que es la programacion orientada al evento?
Bueno lo dejo que me caliento y no paro