Experimentos, reflexiones y otros artefactos (I)

Vamos a iniciar una pequeña serie especialmente dedicada a los programadores que se inician en Delphi y me perdonareis que no tenga la menor idea de cuantos capítulos contiene ni de cuanto tiempo se pueda extender. ¿Uno, dos? ¿quizás tres? ¿veintiuno?. Realmente os confieso que no lo se. Habitualmente se cierran las series en funcion de varias premisas: que hayas dicho todo (resulta raro), que no tengas tiempo para continuarla (supone cerrar uno o varios capitulos rápidamente e intentando que la persona que te lee no note que tienes prisa por acabar) y finalmente, que hayas iniciado un tema y no tengas ni pajolera idea de como acabarlo, bien porque has llegado a un callejon sin salida, bien porque ya no sabes como sacarle mas miga al asunto .

En realidad, mientras escribo me vienen muchas ideas a la cabeza, fruto casi siempre del día a día, pero creerme que resultan dificiles de abstraer a un contexto que sea ejemplar y reducido, como lo puede ser el contenido de un blog. La idea principal, para que me vayais comprendiendo, es quizás concienciar a este programador que se inicia en el entorno, que sufrirá durante toda su vida la tentación de olvidarse de las clases y de la orientación a objetos, para convertirse en un mero «usador» indiscriminado de ellos. Es una paradoja.  Y también una de las maldades que vienen implícitas en el sistema, como el lado oscuro de la fuerza que acompañaba al mítico Jedi. Anteriormente ya he comentado cosas como esta, que siempre he recalcado, y es precisamente por esa razón por lo que el destinatario de estas reflexiones o experimentos, es el programador que da sus primeros pasos en el entorno…

 ¡venga!, ¡vamos!. Si. Tú… Ehhhh… Que te digo a ti…¿no tenías otras cosas que hacer…? ¡No te hagas el remolón que Tú ya sabes mas que las ratas coloradas!. 😉  Y esta serie es solo para los programadores que se inician…

…

Ahora que nos hemos quedado solos (vosotros y este mendrugo que os escribe) y que nos dejan trabajar con tranquilidad, podemos hablar de las cosas sencillas.

Vamos a empezar por un ejemplo muy básico que nos permitirá ir avanzando en estas reflexiones.

Imaginaros que tenemos una producto cualquiera en nuestra manos. Podría ser una bicicleta o un despertador. ¡Qué mas da!. Lo que querais imaginar nos puede servir.

Nos vamos a valer de ese imaginario producto para hacer un ejercicio de abstracción que nos permita asignarle un tipo y un color. Y si llegamos un poco mas lejos, incluso podemos concretar que ambos tipos se definen mediante una cadena de dos caracteres que pueden ser enlazados para formar un hipotético código.

Puestos en esa tesitura, podriamos escribir unas lineas como estas:

//al pulsar el boton Solucion
procedure TmainRelaciones.btnSolucion1Click(Sender: TObject);
var
 i,j: Integer;
begin
   for i := 0 to lbxTipo.Count - 1 do
      for j := 0 to lbxColor.Count - 1 do
          lbxResultados.Items.Add(lbxTipo.Items[i]+ lbxColor.Items[j]);
end;

//al crearse el formulario
procedure TmainRelaciones.FormCreate(Sender: TObject);
begin
   lbxTipo.Items.Add('AA');
   lbxTipo.Items.Add('AB');
   lbxTipo.Items.Add('CC');

   lbxColor.Items.Add('10');
   lbxColor.Items.Add('12');
   lbxColor.Items.Add('15');
end;

lbxTipo, lbxColor y lbxResultados, son tres objetos de la clase TListBox que hemos dejado caer en nuestro formulario. El último, lbxResultados, nos permite concatenar una cadena de 4 caracteres y…

Sencillo. Vale. Hemos resuelto el problema y nuestro jefe estará orgulloso de nosotros porque somos la repera y le hacemos ganar dinero facilmente, PERO no hemos pensado en terminos de objetos ni de clases… Dos bucles for, anidados nos permitieron crear la estructura de un hipotetico código compuesto. Nos ha bastado encontrar un clase (contenedor) para resolver la permanencia y ¡voila!… ¿Os habeis dado cuenta como he remarcado la palabra PERO en la oración anterior?

Es una verdadera pena porque pensar en terminos de clases es bastante divertido y hasta saludable. Y no es que al razonar en  terminos de clases no pueda usarse un bucle for… ¡faltaría mas! ¡alguno habrá que todavía me lo recrimine en los post posteriores!

Como primera reflexión, esta bien ¿no?…

Parece que no estáis demasiado conformes!. 🙂

Bueno. Vale. Extenderé el experimento y nuestro jefe, con ese aire transcendental que le caracteriza, nos comentará que en ocasiones es importante que se puedan alterar el orden de los atributos del artefacto.

Ummmmmmmmmmmmmmmmmmm….

-¡Vale! ¡Ya está!

Nuestro programador siempre encuentra soluciones y en este caso lo resolvió haciendo uso de otro componente, concretamente de la clase TRadioGroup. Éste y una estructura case, y su jefe vuelve a sonreir… 🙂

procedure TmainRelaciones.btnSolucion1Click(Sender: TObject);
var
 i,j: Integer;
begin
   for i := 0 to lbxTipo.Count - 1 do
      for j := 0 to lbxColor.Count - 1 do
          case rgpCodigo.ItemIndex of
           0: lbxResultados.Items.Add(lbxTipo.Items[i]+ lbxColor.Items[j]);
           1: lbxResultados.Items.Add(lbxColor.Items[j]+ lbxTipo.Items[i]);
          end;
end;

Para este programador el formulario es una gran cajon donde se deposita todo y lo mas peligroso de estos razonamientos no es cómo son sus comienzos sino cuales son sus finales.

En sucesivas entradas intentaremos complicarle la vida a nuestro programador y si os parece, de forma similar, le propondremos algunos razonamientos en función de la programación orientada a objetos.