Encapsulamiento en Forms

[mamcx]

La GUI es una parte notoriamente dificil de hacer bien, lo cual se evidencia, entre otras cosas, por la imposibilidad de hacer una GUI multiplataforma realmente buena (solo se puede hasta cierto punto).

El problema que experimentan con Delphi es similar en todos lados: Delphi hereda los problemas del API de windows, de la OOP de entonces. Hacer GUI en web es jodido porque se heredan los problemas de html/css/js. Y así por el estilo. Abstraer esos problemas ayuda en unas cosas, pero tiene el lio de que hay que re-implementar varias otras, por lo que es una propuesta difícil.

Este tema me toca porque llevo dandole vueltas a hacer un lenguaje/herramienta y la parte de la GUI es algo que le llevo cavilando un rato, y nada de lo que hay me convence del todo (no es que no haya una solución: es que implica rehacer los controles!)

Hay formas de hacerlo mejor? Si. Pero requiere ayuda de los lenguajes/herramientas porque como dice:

Empezado por Casimiro

Pero eso toma tiempo, y si tienes a alguien esperando para entregarlo, es imposible "perder" tanto tiempo y al final lo dejas que funcione, aunque no cumpla correctamente la POO.

Si las herramientas, APIs, etc no colaboran el esfuerzo empieza a "cansar" hasta el purista mas dedicado.

Empezado por AgustinOrtu

Existirá alguna manera (o es viable que Embarcadero implemente) la posibilidad de ocultar estos detalles de implementación?

La primera solucion que vino a mi cabeza son interfaces; pero no estoy conforme con eso, ya que es facilmente hackeable ("solucionable"): en vez de usar la interface uso la clase! en un periquete! al demonio con la POO!

Hay varias cosas que son parte fundamental del problema. La OOP? Es uno de ellos!. Especificamente, la *herencia*.

Mal #1: Herencia

Como dice Agustin, el lio es que la herencia arrastra un montón de cosas y hay que esforzarse por "ocultarlas". Ironicamente, se supone que la OO promueve el encapsulamiento, pero la herencia no ayuda en ese sentido.

Peor aun, la mayoría de los toolkits gráficos se basan en armar arboles como TControl -> TEdit -> TEditPassword | TEditNumber -> TEditMoney, etc.

La falla sistematica de esto se evidencia en que cuando se adquiere una libreria (como decir, devexpress, o se usa firemonkey) hay QUE REHACER TODOS LOS CONTROLES. La OO, tal como se hizo popular cuando Delphi nació, ha fallado en su cometido en esta area especifica.

Ahora, OO es un paradigma que combina al dedillo con la GUI, asi que esto es un lio de como se ha usado de forma general...

Mal #2: Coordinacion

El segundo y mas grande problema es de coordinación. Por ejemplo, necesito deshabilitar el boton "Login" si los campos "Password1/2" no cumple con mis N-validaciones.

Aun este escenario "sencillo" muestra que hacer la coordinación es difícil (tipicamente: Requiere regar código en varios lados, hacer callbacks, y rastrear la lógica cuando se hace depuración). Cuando uno entonces intenta hacer una pantalla mas compleja, se nota mucho la carga que el manejo de estado implica ("código spaguetti!").

Mal #3: Estado + Tiempo

El siguiente gran lio es el manejo del estado y como este muta en el tiempo. Quienes hacen apps webs se dan cuenta lo simple -relativamente- que es hacer código de formularios, y eso es porque la web es "sin-estado" por defecto (opera en batch). Esto es facil porque una vez que tengo los datos del formulario, se con exactitud, que esos son los datos y no tengo que coordinarme con nadie mas diferente, si acaso, de la BD, que como esta es transaccional, todo me sale limpio.

EL problema es que el código OO tiende a tener decenas/cientos/miles de estados internos destructivos, y coordinar y estar pendiente de eso se vuelve complicado y difícil de manejar. Combinado con manejar la BD, archivos, eventos del sistema, etc todo se confabula para hacer la vida difícil.

Cuando se tiene código "Sin-estado", estructuras "inmutables" y funciones "idempotentes y sin efectos secundarios" es supremamente mas facil.

Eso es lo que los proponentes de los lenguajes funcionales llevan rato diciendo. Sin embargo, la GUI es nativamente "con-estado y mutable" así que no se puede ir al extremo en este asunto - que es por lo que les ha fallado el mensaje-.

Ademas, es critico que lo que toca la GUI sea rapido, y ahi manejar estado es vital.

----------

RAD no es incompatible con hacer código mas limpio. Sin uno se fija, armar la parte visual de las apps en Delphi es fantastico (mucho mas que en Visual Studio, Xcode... y de ahi en adelante todo es un asco). Es lo que pasa en el *código* lo que complica la cosa.

---------

Como se ve manejo de GUI mejor? Bueno, si han visto el sistema Modelo-Vista-Controlador y similares, entonces no es muy lejos. La Web tiene un modelo casi ideal, lastima que usa DOM, CSS y Javascript! - que lo complica mucho-.

Asi es como seria (usando como ejemplo, una pantalla login):

1- EL modelo es simple:

Código PHP:

//LoginModel es facil de testear, e independiente de plataforma, diseño,
//toolkit y demás!

class LoginModel:
    Email=EmailString
    Pass1=PassString
    Pass2=PassString

//EmailString y PassString son strings que han pasado validaciones y con
//certeza no están vacíos

constructor Login.create(email:EmalString, pass1, pass2:PassString)

function Login.TryLogin():Boolean
//Hacer el login


//Esto valida las cadenas
function isValidEmail(value:string):Boolean

function isValidPassword(value:string):Boolean 


Ahora, esto es solo una idea de modelo. Puede ser aun mas simple (como un hashtable) y no usarse e ir directo al controlador.

-------

Para la parte de GUI, la idea es usar composición en vez de herencia. Ahora el problema es que Delphi, VS usa herencia por todos lados.

Porque composición? Porque en una GUI se reusa un monton de cosas. Por ejemplo, bordes, fondos, captura de eventos de teclado, etc. En vez de tener una arbol profundo de clases, seria ideal poder elejir que usar, como:

Código PHP:

//Supongamos que intento hacer un control de chart de barra

//No heredo nada, excepto declaro soy un control, pero si hago composicion
class ChartBar:UIControl
    //Esto es privado!
    Bar: Rectangle array
    KeyListen: KeyboardListener
    MouseListen: MouseListener

function create()
    this.parent = parent
    this.view.dimensiones = ...
    this.view.Add(Bar)

    this.KeyListen.ListenFor(this.view)
    this.MouseListen.ListenFor(this.view)

//Metodos de negocio!
function draw(values:Integer Array)
    for value in values
        this.Bar[i].draw(width=10, height=value) 


Para coordinar, tengo 2 lios: Como coordino valores con controles, y como coordino el thread de la GUI con el de negocios (para no bloquear la GUI).

Para el primer caso, el modelo reactivo (http://reactivex.io/) y los controles reactivo (https://facebook.github.io/react/) son una gran mejora.

Para el segundo, es el mismo lio que el manejo multi-hilo, el modelo de Actor, pero en especial, el de CSP es todo un avance (https://swannodette.github.io/2013/0...ial-processes/).

-----

Con respecto a que se puede hacer en Delphi? Todo esto (ya el lenguaje es mas que avanzado)

1- La parte de hacer los formularios se puede dejar tal cual
2- Hacer el modelo es trivial en Delphi
3- Hacer el coordinador es la parte compleja, porque Delphi, que yo sepa, no tiene una solucion inmediata.
4- Hacer la parte de multi-hilos es muy viable. Delphi ya tiene muchas mejoras. Implementar CSP estoy viendo como es pero parece ser muy simple...

[roman]

Me extraña un poco no leer en estos mensajes tan interesantes nada acerca de las Acciones. No recuerdo en qué versión de Delphi se introdujeron pero claramente fueron una corrección de Borland para evitar la barbarie de progamar directamente en los manejadores de eventos de los controles visuales. Pero además, las Acciones centralizan las validaciones. Por ejemplo, esto:

Empezado por mamcx

El segundo y mas grande problema es de coordinación. Por ejemplo, necesito deshabilitar el boton "Login" si los campos "Password1/2" no cumple con mis N-validaciones.

Aun este escenario "sencillo" muestra que hacer la coordinación es difícil (tipicamente: Requiere regar código en varios lados, hacer callbacks, y rastrear la lógica cuando se hace depuración). Cuando uno entonces intenta hacer una pantalla mas compleja, se nota mucho la carga que el manejo de estado implica ("código spaguetti!").

yo no le veo problema. Se usa el evento OnUpdate de la acción asociada al botón para hacer las N validaciones.

LineComment Saludos

[[AgustinOrtu]]

Me extraña un poco no leer en estos mensajes tan interesante nada acerca de las Acciones

Cierto, pero tienen un problema.

La aplicacion esta constantemente realizando los chequeos (esta todo el tiempo recorriendo los ActionList y ejecutando los eventos OnUpdate), lo cual puede terminar siendo un gasto innecesario

Saludos

[roman]

No me parece un argumento sólido. En cualquier aplicación siempre hay algo recorriendo los controles y verificando cosas (ya seamos nosotros mismos o el sistema operativo). Desde luego, si las validaciones son muy complejas (como, por ejemplo, incluir consultas a base de datos) se puede ver afectado el rendimiento de la aplicación, pero bien utilizadas no tiene por qué dar problemas. Y, al final de cuentas, las acciones resumen mucho de lo que uno termina programando en aras de evitar lo que comentas desde un principio.

LineComment Saludos

[[AgustinOrtu]]

Sigo pensando que exponer un metodo es mejor

Como ejecutas una accion desde afuera del form en cuestion?

[roman]

Ah, pero es que yo no estoy peleado con lo que propones. Su usamos el manejador de una acción para todo, terminamos simplemente traslandando el problema a otro lugar.

De todas formas, habría que ver las justificaciones en cada caso particular para llamar desde el exterior un determinado método. Por ejemplo, ¿por qué llamar al método GuardarArchivo? No digo que sea el caso, pero posiblemente GuardarArchivo no debería ser, en primera instancia, un método del formulario, sino de otro objeto al cual llama el formulario. Es decir, ¿por qué anexar el método final para guardar un archivo a la interfaz de usuario que pregunta dónde guardarlo? Repito, no es que sea el caso, pero habría que ver en cada situación las justificaciones.

LineComment Saludos

[[AgustinOrtu]]

Yo tampoco estoy peleando, es simplemente un intercambio de ideas

Estoy de acuerdo con lo que propones:

Código Delphi [-]
type
  IGuardadorDeArchivos = interface
    procedure GuardarArchivo(const Ruta: string);
  end;


...

var
  Form: TAlgunForm;
  GuardadorDeArchivos: IGuardadorDeArchivos;
begin
  GuardadorDeArchivos := TGuardadorDeArchivos.Create;
  Form := TAlgunForm.Create(Self, GuardadorDeArchivos);
end;

// en algun otro punto se puede disparar esto

procedure
begin
  GuardadorDeArchivos.GuardarArchivo('C:\nueva carpeta\');
end;

Eso es genial, pero lo que a mi me molesta es que si yo quisiera, podria hacer esto:

Código Delphi [-]
procedure
begin
  Form.ActionList1.Actions[0].ExecuteTarget(NIL);
  Form.ActionGuardarArchivoExecute({hay que mandar un parametro sender ¡?¡?¡?¡});
end;

La "solucion" es meter el ActionList en la parte privada del form e instanciarlo en runtime

Pero es muy incomodo, a todos nos gusta diseñar forms con el IDE; por codigo es mucho mas tedioso (una subclase de TForm es "posible" manejar el layout de todo los controles por codigo, pero cuando estas por los tataranietos de TForm?? se hace imposible)

Código Delphi [-]
type
  TFormAlgo = class(TForm);
    // todo lo que esta desde aca hasta el "private" es accesible desde afuera! esto me molesta mucho
    edRutaArchivo: TEdit;
    btnAceptar: TButton;
    btnCancelar: TButton;
  private
  end;

[mamcx]

Empezado por roman

En cualquier aplicación siempre hay algo recorriendo los controles y verificando cosas

.... si las validaciones son muy complejas (como, por ejemplo, incluir consultas a base de datos) se puede ver afectado el rendimiento de la aplicación

Claro que es así. El asunto no es de posibilidades, sino de comodidad , pero mas importante, de claridad y que el código sea correcto.

El problema de la GUI es que los datos se "mueven" en el tiempo, y esto muta los objetos. Mantener la coordinación requiere moverse entre varios lugares (que cierto que acciones y demás cosas ayudan). La idea aqui es como evitarlo? Como centralizarlo? Como "aplanar" el proceso?

-----
Pensemos por ejemplo, en el caso de la pantalla de login, que ademas chequea en tiempo real si el usuario ya esta tomado, y obtiene el gravatar de ese correo. Debe ademas actualizar la interface de forma correcta, no interrumpir y que ademas cuando le de "Login" cancele cualquier solicitud de red pendiente.

En un estilo tipico, esto seria relativamente engorroso de hacer. Veamos como es al estilo de "Programacion Reactiva". Me perdonan la syntaxis inventada pero me di cuenta que si lo hago en otros lenguajes le puedo meter cosas que tocaria explicar.

Código PHP:

FetchNetwork = Events.
    ([email], TextChange)
    .each(function edit, event
        return IsValidEmail(edit.text)
    //Ejecutar concurrentemente las llamadas de red, sin esperar la anterio
    ).nextAsync(function edit
        fetchGravatar(edit.text)
    ).nextAsync(function edit
        isEmailTaken(edit.text)
    //Cuando obtengo ambas respuestas...
    ).merge(function img, isTaken
        if isTaken
            return False

        form.imgUser.Load(img)

        return True
    )
//Password parecen validos, y son iguales
IsValidPass = Events.
    ([Pass1, Pass2], TextChange)
    //Por cada control...
    .each (function edit, event
        return IsValidPassword(edit.Text)
    )
    .merge()
    .filter(function result1:bool, result2:bool
        //Si son iguales
        result1==result2
    )

//Combino todo
Loop = Events.([IsValidPass, FetchNetwork])

//Cuando login Ok, cancelo el proceso de eventos

Loop.Stop() 


La parte importante, es que se puede hacer composicion de eventos, que estos hacen cascada y que solo continuan cuando el anterior tiene exito (o saca error, y se va al manejo de errores), por lo tanto, si esto en .filter(function result1:bool, result2:bool) ya se con certeza que las claves son validas y solo queda averiguar si son iguales. Se tengo que agregar otros edits no hay problema, y como puede hacer composicion y combinan eventos, puedo generar una libreria de soluciones universales y re-combinar al gusto.

El estilo anterior tiene la contra de que es un monton de callbacks y eso se pone algo pesado a la vista. Es mucho mas limpio si se hace con Communicating sequential processes, pero lastima no hay mucho de eso en el mundo GUI.

El asunto es que se requiere algo de ayuda del lenguaje para que sea natural de operar.

[Ñuño Martínez]

No olviden que no es necesario programar "en visual". Me explico: crear componentes con código. Puedes crear toda la aplicación sin usar el diseñador ni los recursos, haciendo herencia, poniendo los componentes en la sección PRIVATE de nuestros objetos de ventana... Mucho más OO, y encima genera ejecutables más pequeños.

[[AgustinOrtu]]

Claro que se puede, pero es más difícil

Diseña un reporte con una línea de herencia de 3 o 4 clases, vamos que no está fácil