Qualunque alternativa pratica al modello di Segnali + Slot per la programmazione GUI?

Anche se non lo chiamerei tutto così popolare, c'è sempre programmazione reattiva per le GUI, in particolare programmazione reattiva funzionale , come implementato, ad esempio, dal . NET Rx Framework , oltre a diversi toolkit in linguaggi / piattaforme un po 'più esoterici, come reactive-banana o FrTime , per Haskell e Racket rispettivamente.

Questo è un mio argomento preferito, e per circa un decennio (anni '70 -'86) ho pensato che avere una GUI composta da oggetti che rispondessero agli eventi fosse il modo giusto per farlo.

Poi mi sono imbattuto in un altro modo per farlo descritto qui e con un progetto sourceforge qui .

In poche parole, il problema con gli oggetti è che persistono, e se scrivi codice per crearli, devi anche scrivere codice per modificarli in modo incrementale se sono necessarie modifiche e in qualche modo ottenere messaggi da e verso di essi. Non sarebbe bello se tu potessi solo dipingere ciò che volevi, e poi ridipingerlo se vuoi qualcosa di diverso, e non dovresti preoccuparti della persistenza degli oggetti precedenti? Non sarebbe bello anche se non avessi mai dovuto scrivere il codice per la gestione dei messaggi, perché è tutto fatto sotto il cofano?

Questo è ciò che fa questo pacchetto. Per finestre di dialogo semplici, salva un ordine di grandezza nel codice. Per le finestre di dialogo dinamiche che cambiano dinamicamente, le rende possibili.

P.S. L'ho fatto solo per le interfacce utente desktop e le interfacce utente remote, non le interfacce utente del browser web. Sono sicuro che sia possibile, ma non ho avuto la possibilità di provarlo.

Bene, ci sono due modi distinti per questo:

1. Chiedi a ogni widget di esporre un meccanismo di sottoscrizione granulare (Segnale / Slot, Osservatore / Osservabile, Evento / Delegato) e abbonati al codice client e agisci di conseguenza.
2. Costruito un widget contro un'astrazione dei dati che presenta e il codice client implementa tale astrazione.

Ecco un esempio del secondo approccio:

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

Ora puoi creare un LabelButton rispetto a LabledAction e il codice client può solo implementarlo o utilizzare alcune implementazioni predefinite generiche, se disponibili e adatte.

In un certo senso il secondo approccio è meno flessibile, ma più rigido. Non si limita in qualche modo a collegare la vista con il modello attraverso mezzi relativamente atomici. Si progetta una GUI adatta in base alle proprie esigenze e quindi si implementano gli adattatori tra quella GUI e la logica del dominio / dell'applicazione.

Alcuni sistemi di controllo utilizzano un approccio al database: ciascun controllo dell'interfaccia grafica è collegato a un file archiviato nel database in modo che il Gui rifletta sempre lo stato del database. I ganci DB vengono utilizzati per attivare le funzioni quando un valore cambia.