Considerazioni finali
Come si può osservare in questo articolo, tutta la gestione delle modifiche e della storia di un elemento derivato da DB_OBJECT è gestito in modo completamente astratto rispetto all’oggetto. Solo le due azioni terminali di inizializzazione dell’azione e di ripristino sull’oggetto sono ovviamente specifiche dello stesso;
tutto il ciclo è effettuato sfruttando l’eredità delle interfacce di OPERATION_CALL, ACTION, PARAM e DOCUMENT_HISTORY. La classe WIDGET_DOCUMENT, di cui scriveremo prossimamente eredita da Wnd_Interface la gestione dei messaggi del sistema operativo;Quindi in modo completamente trasparente reidirizza la messaggistica verso le classi documento o widget ai quali è collegata tramite gli slot.
Il paradigma degli SLOT di colibri è alla base di tutta la gestione delle interazioni fra i suoi oggetti.
L’interfaccia OPERATION_CALL, assegnabile a qualunque oggetto costruito mediante le API di Colibri permette di attivare la connessione con SLOT appartenenti a moduli e dll differenti.
L’interfaccia DOCUMENT_HISTORY può essere assegnata anch’essa a qualunque classe, semplicemente dichiarandone l’eredità. Questa condizione permette di gestire la storia di un qualunque oggetto, permettendone la navigazione attraverso i suoi stati, usando le funzioni standard previste nell’interfaccia.