encapsular codigo de delphi

[thelibmx]

hola amigos desde hace tiempo tengo esta duda, hay manera de que un codigo que se va ejecutar muchas veces en diferentes partes de un programa en delphi se pueda encapsular para su reutilizacion?, no se si me explique bien, suponiendo que tengamos una ventana con un panel, en el cual tenga 5 cajas de texto tedit; entonces podemos dar altas bajas y modificaciones, entonces cuando se trata de altas blanqueamos los tedit y pues de igual manera en modificacion, y bajas, entonces iria algo asi como

Código Delphi [-]
edith1.text:='';
edith2.text:='';
edith3.text:='';
edith4.text:='';
edith5.text:='';

suponiendo que hay un boton de alta, otro de baja y otro de modificacion, iria esas 5 lines en cada boton, y si lo encapsulo pues solo mando llamar ese proceso o ese conjunto de instrucciones en una sola linea y no repito el codigo 5 veces, este es un ejemplo muy sencillo pues son 5 lineas, pero que pasa cuando son mas de 50 lineas de codigo, hay alguna manera de encapsularlo y reutilizarlo sin tener que repetir todo el codigo espero haberme explicado bien, gracias

[[poliburro]]

es cuestión de aprovechar la OOP, por ejemplo, creas una clase que hereda a TForm, pero que implemta el método para limpiar todos los EditBox de un contenedor en particular.

Al heredar en tu código cada Form de tu Propia forma, podrás reutilizar el método de limpieza.

Eso es solo un ejemplo.

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

Empezado por thelibmx

...suponiendo que hay un boton de alta, otro de baja y otro de modificacion, iria esas 5 lines en cada boton, y si lo encapsulo pues solo mando llamar ese proceso o ese conjunto de instrucciones en una sola linea y no repito el codigo 5 veces, este es un ejemplo muy sencillo pues son 5 lineas, pero que pasa cuando son mas de 50 lineas de codigo, hay alguna manera de encapsularlo y reutilizarlo sin tener que repetir todo el codigo

Colocalas en un procedimiento/función (con parámetros si lo necesitas) y utilízalo tantas veces como quieras.
¿A eso te refieres?

[dec]

Hola,

Bueno. En el caso concreto de los "TEdit" que dices... tal vez podrías preparar un procedimiento que se encargara de recorrer en un determinado contenedor (por ejemplo un formulario) todos sus controles, comprobar cuáles son "TEdit", y utilizar el método "Clear()" de estos últimos cuando sea así. Algo similar a esto:

Código Delphi [-]
procedure ClearEdits(container: TWinControl);
var
  i: integer;
begin
  for i := 0 to container.ControlCount-1 do
  begin
    if (container.Controls[i] is TEdit) then
      TEdit(container.Controls[i]).Clear();
  end;
end;

Pero se te pueden ocurrir otras ideas, como, por ejemplo:

Código Delphi [-]
procedure ClearEdits(container: TWinControl;
 edits: array of TCustomEdit);
var
  i: integer;
begin
  for i := Low(edits) to High(edits) do begin
    if (container.FindChildControl(edits[i].Name) <> nil) then
      edits[i].Clear();
  end;
end;

Con este último procedimiento no es preciso borrar "todos los edits", sino sólo los que quieras, de una forma similar a esta:

Código Delphi [-]
ClearEdits(self, [Edit1, Edit2, Edit3]);

[[Lepe]]

Otro más:

Usa un Frame, colocas los 5 edits, los botones de limpieza.... y listo. Cuando quieras usar añades el frame a la ventana / panel que deseas y ya lo tienes implementado.

Para crear el frame: File -> New -> (other) -> Frame
Para añadirlo a una ventana: Paleta de componentes -> Standard -> frame -> clic sobre el Form y te saldrá una lista de frames existentes en tu proyecto.

Yo por ejemplo tengo DBGrid que hace muchas cositas:
- Propiedades preestablecidas (ancho y alto de celdas, etc)
- coloreo de filas alternas
- multiordenación de columnas
- Formateo de números (negativos en rojo; muestra el total en euros de un color si está pagado o no, etc).

Todas las funcionalidades estan dentro del frGrid (FRameGrid). Si necesito un Grid, no tengo que usar el de la paleta de componentes y establecer todo de nuevo, directamente pego mi frame.

Otro ejemplo: un frame que contiene 1 Edit y un combo, el Edit para introducir el código de cliente y el combo para mostrar el nombre, de forma que siempre estén sincronizados (al escribir en uno, se actualiza los datos del otro).

El resultado es como si tuvieras un nuevo componente de la paleta de delphi, que hace lo que tú quieres. El código fuente solo está en una unidad, por lo que no se duplica código fuente.

Espero que estos ejemplos te ayuden a pensar en verde .

Saludos

Saludos

[thelibmx]

Empezado por Neftali

Colocalas en un procedimiento/función (con parámetros si lo necesitas) y utilízalo tantas veces como quieras.
¿A eso te refieres?

si,mi idea iba mas orientada a un procedimiento o funcion, es decir que se meta cierto codigo en el procedimiento o funcion y despues mandarlo a llamar, estoy empezando en esto y no se mucho sobre como deberia ser la estructura del procedimiento o la funcion, es decir si quisiera hacer un procedimiento en donde debo declararlo y que es lo que tengo que hacer?, si debe de ir antes o despues de llamarlo?, si se declara en los procedures ? etc.. pues he intentado hacerlo como si fuera procedimiento pero no encuentro la sintaxys correcta, ni la forma en como se manda a llamar, no tengo ahorita un caso en especifico, pero he hecho algunos programas y he tenido que repetir todo el codigo en cada boton por no poder hacerlo y eso como que no se ve bien,creo que dec a puesto un ejemplo de los procedimientos y como utilizarlos, podrian poner un ejemplo de como se haria si fuera funcion y como seria si fuera procedimiento, se los agradeceria mucho, de todos modos tomare en cuenta todas las formas que han escrito para investigar mas a fondo y entender un poco mejor. gracias por su atencion amigos

[[Delphius]]

Hola thelibmx,

Según entiendo, y considerando que dices que recién estás empezando. La opción de Dec es la más adecuada para ti. De hecho, yo estoy haciendo cosas así, funciones de "proposito general" que reciben arrays de controles.

Creo que el ejemplo que te puso Dec es ilustrativo.
A los fines y propósitos de lo que es "Limpiar Edits", no tiene utilidad convertir dicho procedimiento en una función. De poder se puede, pero a mi modo de ver... no se ajusta lo deseado a una función. Recuerda que una función debe devolver un valor, un resultado. ¿Que valor debería o podría devolver una función que tiene como propósito limpiar edits? No se si me explico.

Lo que puedes hacer es tener una unidad con procedimientos y/o funciones de "propósitos generales" Por ejemplo una unidad ULimpieza que se encarga de hacer labores de limpieza, en ella podrías tener un variado conjunto de procedimientos o funciones que realizan limpieza según los controles y/o parámetros que necesites. Una vez que tienes esta unidad sólo es cuestión de agregar en la sección uses de alguna otra unidad en donde sea necesario llamar o usarlas.

No se si me explico. Tu unidad ULimpieza no tiene un form asociado. Es una unidad simple... tu sólo deberás llamarla cuando sea necesario.

Puedes luego, cuando afianses tus conocimientos, probar las otras opciones: Frames y/o Forms que puedas reutilizar en base a la herencia visual. Esto requiere de un poco más de astucia y son conceptos un poco más complicados. Por ello te digo que comiences teniendo la ULimpieza y después ver como ir aumentandola y/o adaptarla a Frames o Forms de herencia.

Si necesitas que te ayudemos a armar dicha unidad y/o si sigues teniendo dudas ya sabes. Puedes contar con nosotros.

Saludos,

[thelibmx]

ok aqui hay un caso practico sencillito,igual y me pueden dar una mejor manera de optimizarlo o me pueden dar alguna sugerencia, veran tengo el siguiente codigo

Código Delphi [-]
 
procedure TFormquincena.Button3Click(Sender: TObject);
var
Count1,pos: integer;
text: string;
begin

//llenado de combo box de años de quincena
    Pos := ComBoxselectoranio.SelStart;
    ComBoxselectoranio.Items.Clear;
    Text := ComBoxselectoranio.Text;
formconecciones.Query_catalogo_quincenasmod.Close;
formconecciones.Query_catalogo_quincenasmod.SQL.Clear;
formconecciones.Query_catalogo_quincenasmod.SQL.Add('select distinct anio from catalogo_quincenas');
formconecciones.Query_catalogo_quincenasmod.ExecSQL;
formconecciones.Query_catalogo_quincenasmod.Open;
 Count1:=formconecciones.Query_catalogo_quincenasmod.RowsAffected;

    if Count1 > 0 then
     begin
      repeat Dec(Count1);
      ComBoxselectoranio.Items.Add(formconecciones.Query_catalogo_quincenasmod.FieldByName('anio').AsStrin  g);
       formconecciones.Query_catalogo_quincenasmod.Next;
      until Count1 = 0;
      ComBoxselectoranio.ItemIndex := 0;
      ComBoxselectoranio.SelStart := Pos;
      ComBoxselectoranio.SelLength := 255;
    end;
//llena combobox año  de quincena
 
end;

bien con ese codigo lo que hago esque lleno un combobox con los años que se encuentran en una tabla. Entonces al yo apretar un boton, pues trae todo los resultados y los mete al combobox, cuando yo corro mi programa en el evento form create se encuentra ese codigo, entonces se ejecuta y me llena el combo con los años que estan en ese momento en la tabla, digamos 1999,2000,2003, ok, ahora bien, tengo en un panel, con tedit, y desde ahi puedo insertar mas años en la tabla, digamos que 2004,2005,2006, como al crear el formulario se leyeron los que ya habia, ahora necesito que vuelva a ejecutar esa parte de codigo para que aparezcan los años agregados,entonces lo ideal creo yo seria meter esa parte de codigo en un proceso, para que cuando yo inicie la forma solo mande llamar ese proceso o cuando agregue un nuevo año, se mande a llamar el proceso, entonces lo que hago es esto

Código Delphi [-]
procedure llenadocombo();
var
Count1,pos: integer;
text: string;
comboxselectoranio:tcombobox;
begin
//llenado de combo box de años de quincena
    Pos := ComBoxselectoranio.SelStart;
    ComBoxselectoranio.Items.Clear;
    Text := ComBoxselectoranio.Text;
formconecciones.Query_catalogo_quincenasmod.Close;
formconecciones.Query_catalogo_quincenasmod.SQL.Clear;
formconecciones.Query_catalogo_quincenasmod.SQL.Add('select distinct anio from catalogo_quincenas');
formconecciones.Query_catalogo_quincenasmod.ExecSQL;
formconecciones.Query_catalogo_quincenasmod.Open;
 Count1:=formconecciones.Query_catalogo_quincenasmod.RowsAffected;
  showmessage(inttostr(count1));
    if Count1 > 0 then
     begin
      repeat Dec(Count1);
      ComBoxselectoranio.Items.Add(formconecciones.Query_catalogo_quincenasmod.FieldByName('anio').AsStrin  g);
       formconecciones.Query_catalogo_quincenasmod.Next;
      until Count1 = 0;
      ComBoxselectoranio.ItemIndex := 0;
      ComBoxselectoranio.SelStart := Pos;
      ComBoxselectoranio.SelLength := 255;
    end;
//llena combobox año  de quincena
end;

y pues para mandarlo llamar seria algo asi

Código Delphi [-]
procedure TFormquincena.FormCreate(Sender: TObject);
begin
llenadocombo();
end;

o si se tratara de un boton seria algo asi

Código Delphi [-]
procedure TFormquincena.Button4Click(Sender: TObject);
begin
llenadocombo();
end;

pero asi me manda un error de acces violation at adress 004ebc55 in modulo' modulo' .Read of adress 5s0000, cada ves que mando a llamar el procedimiento por medio del boton, o por el evento form create y asi me ha pasado con otros codigos que he querido intentar encapsular, se q algo estoy haciendo mal, tenganme mucha paciencia, no se desesperen se que es una tonteria, tal ves error de sintaxys o algo que no he declarado no se, enseñenme la luz jejeje gracias por su atencion

[[Delphius]]

Hola nuevamente thelibmx,
Estuve haciendo unas diligencias y ya volví.

El error te que arroja se debe a que tu procedimiento LlenadoCombo tiene una variable del tipo TComboBox, precisamente la variable comboxselectoranio. Dicha variable en ningún momento está asociada a algún control y/o está instanciada (para tener acceso a dicha variable debes primero crearla). Por lo que entiendo, en el procedimiento Button3 cuando invocas al combo lo haces a un combo ya instanciado, pues existe en memoria y está asociado a un form.
Cuando declaraste la variable dentro del procedimiento, el compilador interpreta correctamente que se trata de un combo pero como nunca fue creado, provoca dicho error.
La solución sería borrar dicha variable y tener el procedimiento en alguna parte (posiblemente en la parte private) de la unidad asociada de la form para mantener la referencia al combo.

La otra posibilidad es que alteres a LlenadoCombo para que reciba por parámetro el combo. Es decir:

Código Delphi [-]
procedure LlenadoCombo(Combo: TComboBox);

Vas bien.

Aprovecho para recomendarte que si deseas conseguir una mayor modularidad y beneficiar la reutilización que evites mezclar la lógica, con la parte de acceso a datos y hacia con la parte de la interfaz. No es sencillo conseguir eso. Pero es preferible tener separado en una parte las funciones y procedimientos que hacen a cuestiones exclusivas a interfaz en un lado, por otro lado las funciones que tienen que ver con el acceso a los datos y por el otro la lógica.
En ocasiones es sencillo particionar el código... en otras es inevitable.
Esto se consigue, como la mayoría de las cosas de la vida, con la práctica y un buen diseño y planteo del problema.

Como ayuda puedes hacer lo siguiente:
Ve al sistema desde 3 puntos de vista:
1. Lo que debe hacer la interfaz. Confeccciona una lista de funcionalidades que hacen al empleo de la interfaz.
2. Haz la misma lista, pero esta vez sólo para lo relacionado con el aspecto a base de datos.
3. Ahora por último, lo más complicado: La lógica. Es aqui el problema debes conseguir armar un juego de funcionalidades que permitan dirigir el programa hacia ambos puntos: la interfaz y hacia el acceso a datos. Con ambas listas en mano busca aquellos puntos (funcionalidades) que se unen y/o que forman una "dependencia I/D" (I de interfaz y D de Datos). A cada dependencia le asocias un nombre, un evento lógico que tenga sentido. Declaralo en forma de procedimientos o funciones y trata de mantener cada "dependencia" tan separado de las otras. Es posible que hayas relaciones entre ellas.

Bueno espero que se me entienda. Esto es un TIP. Hay varias maneras de conseguir modular un sistema... esta es la más simple que se me ocurre.

Saludos,

[thelibmx]

sobre la primera opcion no entendi muy bien no me quedo claro muy bien intente entender pero no entendi jejej, la segunda opcion si la capte mejor, y ya la implemente y hace mas o menos lo que queria, es un proceso que le paso un parametro para hacerlo, no se si era la idea pero ilustro un poco como lo hice, se manda a llamar asi

Código Delphi [-]
procedure TFormquincena.FormCreate(Sender: TObject);
begin
llenadocombo(ComBoxselectoranio);
end;

y el codigo de proceso es asi

Código Delphi [-]
procedure llenadocombo(Combo: TComboBox);
var
Count1,pos: integer;
text: string;
begin
    Pos := ComBo.SelStart;
    ComBo.Items.Clear;
    Text := ComBo.Text;
formconecciones.Query_catalogo_quincenasmod.Close;
formconecciones.Query_catalogo_quincenasmod.SQL.Clear;
formconecciones.Query_catalogo_quincenasmod.SQL.Add('select distinct anio from catalogo_quincenas');
formconecciones.Query_catalogo_quincenasmod.ExecSQL;
formconecciones.Query_catalogo_quincenasmod.Open;
 Count1:=formconecciones.Query_catalogo_quincenasmod.RowsAffected;

    if Count1 > 0 then
     begin
      repeat Dec(Count1);
      ComBo.Items.Add(formconecciones.Query_catalogo_quincenasmod.FieldByName('anio').AsString);
       formconecciones.Query_catalogo_quincenasmod.Next;
      until Count1 = 0;
      ComBo.ItemIndex := 0;
      ComBo.SelStart := Pos;
      ComBo.SelLength := 255;
    end;
end;

asi ya hace lo que queria, aunque supongo que la forma que a mi me interesaba era la primera opcion que pusiste Delphius,pero no supe como ponerla en marcha, me da pena decirlo pero podrias tratar de explicar un poco mejor la primera opcion si pudieras tal ves con codigo de ejemplo, si es que cuentas con tu tiempo por que la verdad no quiero abusar, con lo que has dicho me has ayudado mucho, y gracias con los tips, los tomare muy en cuenta, todo el conocimiento que se pueda aprender es bienvenido, de nuevo gracias Delphius y gracias a todos los que contestaron este hilo

[[Delphius]]

Hola nuevamente.

thelibmx disculpa si no me di a entender. La primera versión no te anda porque tienes declarado como variable un Combo que en ningún momento fue creado para reservarle memoria. El compilador no protesta cuando le pones Combo.propiedad := algo pero en el momento de ejecución cuando intenta acceder a la zona de memoria destinada para dicho combo se da con que no existe. Por lo tanto protesta arrojandote el error. La solución:
1. Crearlo.
2. Operar con el
3. Mostrarlo, fue creado pero no está visible. Hay que darle un lugar donde mostrarlo.

Una opción (muy simple por cierto) para conseguir esto es la que doy a continuación, basada en tu código. No la he probado, la escribí a mano... no tengo Delphi a mano. Debería andar.
Hice el supuesto que la forma en donde estará el combo se llama form1.

Código Delphi [-]
procedure llenadocombo;
var
Count1,pos: integer;
text: string;
comboxselectoranio:tcombobox;
begin
// para que te funcione la variable es necesario primero reservar memoria:
// como ejemplo hice que sea Form1 el "dueño" del Combo, Form1 se encargará
// de liberar la memoria de Combo
 comboxselectoranio := TComboBox.Create(Form1);

//llenado de combo box de años de quincena
    Pos := ComBoxselectoranio.SelStart;
    ComBoxselectoranio.Items.Clear;
    Text := ComBoxselectoranio.Text;
formconecciones.Query_catalogo_quincenasmod.Close;
formconecciones.Query_catalogo_quincenasmod.SQL.Clear;
formconecciones.Query_catalogo_quincenasmod.SQL.Add('select distinct anio from catalogo_quincenas');
formconecciones.Query_catalogo_quincenasmod.ExecSQL;
formconecciones.Query_catalogo_quincenasmod.Open;
 Count1:=formconecciones.Query_catalogo_quincenasmod.RowsAffected;
  showmessage(inttostr(count1));
    if Count1 > 0 then
     begin
      repeat Dec(Count1);
      ComBoxselectoranio.Items.Add(formconecciones.Query_catalogo_quincenasmod.FieldByName('anio').AsStrin  g);
       formconecciones.Query_catalogo_quincenasmod.Next;
      until Count1 = 0;
      ComBoxselectoranio.ItemIndex := 0;
      ComBoxselectoranio.SelStart := Pos;
      ComBoxselectoranio.SelLength := 255;
    end;
//llena combobox año  de quincena

 // Lo hago visible, es decir lo muestro...
 // Lo correcto sería indicarle la posición
 comboxselectoranio.Parent := Form1;
end;

Ahora, esto es una opinión mia. En lo preferente evito estar declarando objetos visuales, crearlos y mostrarlos como el código que puse. Esto reduce la utilización, ya que hace en el código mismo se hace la asignación del dueño del componente. Con lo cual se forma una dependencia entre el procedimiento y la forma "dueña".

Esta relación puede romperse. Esto se consigue con la segunda versión del procedimiento, la que recibe el parámetro. Esto favorece la reutilización ya que se ha desplazado la responsabilidad de asignar el "dueño" a otro; el procedimiento solamente se encarga de llenarlo, de "quien" es el combo... no le incumbe. Que se consigue, esto:

Código Delphi [-]
LlenarCombo(form1.ComboAños);
LlenarCombo(form2.MiCombo);

¿Ves la diferencia? Ahora LlenarCombo puede ser usado en cualquier lado... bueno... no tanto... todavía mantiene otra dependencia: formconecciones. Podemos mejorarlo. Hacerlo que ya no dependa de un form para acceder a un TQuery. ¿Porqué no hacerlo que lo haga de un DataModule y desplazar la dependencia hacia la capa de datos, que es donde probablemente mayor sentido tiene? O mejor aún... dejamos que LlenarCombo sea de la capa lógica... que no "dependa" de ni la capa de interfaz ni la de la capa de datos? ¿Como hacer esto?

Código Delphi [-]
procedure LlenarCombo(Combo: TComboBox; Desde: TQuery);

Este procedimiento no debería encargarse de lanzar la consulta. Sólo debería recorrer los registros devueltos por la consulta, lanzada en un momento anterior y llenar el combo.

Con esto en mente se puede hacer algo como esto:

Código Delphi [-]
LlenarCombo(Form1.ComboAnio, DM1.QueryAnio);

Ahora si esta lindo, limpio. Un procedimiento que no está declarado en ningún form, puede que incluso fuera del DataModule... está en la capa lógica, en una unidad ULimpieza si se quiere.

Habrás notado que dije anteriormente "no dependa". Esto no es totalmente posible. SIEMPRE existe dependencia, podemos reducir el "ruido" entre las dependencias pero no eliminarlo. Un objeto (función, procedimiento, units, etc) que no mantenga dependencia tiene dos defectos:
1. No sabe designar responsabilidades y hace todo el trabajo por si mismo. O bien...
2. A sido mal diseñado e implementado. Ya que no sabe para quien debe "trabajar".

thelibmx me alegro serte de ayuda, pero sigue mi consejo. No te quedes con lo simple que te comenté. Hay varias maneras de llevar un trabajo modular... lo que expuse es una filosofía que he desarrollado y como filosofía no es totalmente certera ni abosulta. Muy seguramente hay otras personas que también tienen otro punto de vista y distinta manera de ver las cosas.

Recuerda esto también: antes de llevar a cabo la modularización debes saber manejar e imponer un precio al tamaño de esto. Debes saber que un buen sistema modular no debe tener demasiado módulos, pero tampoco muy pocos. ¿Cuanto es demasiado?¿Cuanto es muy poco? Tu sabrás, dependiendo de la naturaleza del problema, de los requisitos y el sentido común hasta donde llegarás para decidir que va en un módulo, que va en otro... Esto no es ciencia exacta, lamentablemente (aunque para mi es lo que hace lindo a la informática)

Saludos,

[thelibmx]

ok Delphius, creo que ya entendi mejor lo de la primera opcion, pense que seria mas sencillo, pero creo que sale peor el remedio que la enfermedad, en fin, agradesco mucho tu ayuda y el tiempo proporcionado, aprendi mucho, por mientras implementare lo de la segunda opcion y tendre en cuenta los tips que has puesto amigo, gracias