cronologia e aree di applicazione del paradigma di programmazione 'pull' / 'push'

Può essere difficile conciliare i modelli push con la separazione delle preoccupazioni. L'accoppiamento lento, generalmente considerato una buona pratica, significa progettare i componenti del sistema con dipendenze minime e la minima conoscenza possibile della struttura generale e di altri componenti. La semantica spinta o la interrompe (se implementata in modo semplicistico) o aggiunge una complessità significativa (c. Il schema di osservazione ); in entrambi i casi, almeno un componente necessita di una buona conoscenza di tutti i suoi dipendenti per implementare la spinta.

Mantenere un accoppiamento lento tra componenti in un sistema basato su eventi richiede un corrispondente aumento della complessità del sistema complessivo e può, perversamente, accoppiare strettamente ogni componente alla semantica del modello di eventi. Ciò può rendere difficile estendere o alterare il modello, in modo che i progettisti del sistema scoprano di aver semplicemente sostituito una serie di vincoli con un'altra. I meccanismi Pub / Sub (ad esempio Message Queues) sono molto inclini a questo, ma è un problema generale.

Per semplici esempi del mondo reale guarda l'e-mail. Il recapito della posta SMTP è un modello push; è molto robusto, ma si è rivelato molto difficile da estendere per affrontare scenari imprevisti (lo spam sarebbe il classico esempio, ma guardate anche problema che ETRN e ATRN sono stati sviluppati per affrontare, e in che modo parzialmente e incoerentemente quelli sono stati adottati). Guarda quanto SMTP è più complesso di POP o persino IMAP (entrambi essenzialmente modelli pull) e quanto altro lavoro è necessario per renderlo resiliente.

Storicamente, la complessità dei meccanismi di spinta li ha resi più difficili da implementare. La nostra capacità di questa complessità è aumentata nel tempo. Tuttavia, i sistemi basati sugli eventi hanno le proprie insidie.

Vorrei mettere in dubbio che tutti i domini che modelliamo stanno cambiando rapidamente. Il contesto in cui le usiamo può diventare più complesso (e più ricco), ma alcuni problemi rimangono semplici. L'accoppiamento lento è uno dei modi in cui limitiamo la necessità di modificare i singoli componenti mentre il sistema che li circonda cambia.

Anche oggi, ci sono alcune aree, in cui devi tirare i dati, perché un'opzione push non è semplicemente disponibile per te. Per quanto ne so, questi sono stati in giro per molto tempo, così che i primi sistemi potrebbero aver semplicemente accettato da quelli che tirano è la strada da percorrere.

Iniziamo con un esempio molto semplice: vuoi monitorare una cartella sul tuo hard disk e fare qualcosa ogni volta che un nuovo file appare in quella cartella. Nelle lingue moderne, ti vengono offerte delle astrazioni che ti consentono di registrare una sorta di listener, che verrà chiamato una volta che viene rilevato un file. In precedenza, quando queste astrazioni non erano ancora disponibili, dovevi verificare da solo, tirando continuamente le informazioni sulla cartella e cercare un nuovo file.

Sebbene ciò possa sembrare vecchio, il problema si ripresenta in una situazione moderna, quando si passa da una semplice cartella a f.ex. un repository di codice sorgente. Molti di noi hanno un server CI come Jenkins in esecuzione, ed ecco, come fa a sapere che qualcuno ha commesso qualcosa nel repository SVN del progetto? Estrae i dati dal repository ogni x minuti (o qualunque cosa sia configurata per l'intervallo di pull). Come al solito, potremmo investire qualche sforzo per spostarlo verso un'implementazione push-style, ma dovresti trovare qualcosa che funzioni per tutte le implementazioni di repository di codice, il che non è poi così semplice.

Infine, nell'area embedded, l'approccio pull è stato predominante per molto tempo e non andrà via tanto presto. Quando si dispone di un hardware semplice a cui è possibile accedere, spesso si finisce per dover estrarre i dati e verificare le modifiche. Solo elementi hardware di livello superiore, come una CPU, possono fornire astrazioni su questo. Al livello più basso, tuttavia, hai semplicemente 0 e 1, spento o acceso.

Per questo motivo, presumo che il primo sviluppo del software, che era ancora vicino al livello hardware, fosse influenzato dal fatto di dover estrarre dati da elementi hardware. Conosco ancora molti programmatori incorporati, che scrivono ancora loop di polling senza fine che continuano a ricevere gli ultimi dati dei sensori per fare cose ogni volta che si verifica un cambiamento abbastanza significativo. Quindi scrivere codice pull-based sembra venire naturalmente da questa prospettiva.

Ciò che abbiamo fatto in passato, però, era aggiungere un livello di astrazione in cima, il che ci ha dato l'intuizione che un approccio push è molto migliore sotto molti aspetti. Quindi, abbiamo continuato a cercare modi per spostarci da uno all'altro. La gente si è resa conto che se un orologio può essere implementato in modo tale che tutti gli osservatori vengano semplicemente notificati tramite un approccio push-style, il nostro software risultante che dobbiamo scrivere diventa molto più facile, quindi più economico e più veloce sul mercato.

Per rispondere alla tua domanda sull'adeguatezza: se hai già un'interfaccia push-style disponibile per l'uso, molto probabilmente è l'alternativa migliore. Ma ci sono casi in cui non hai ancora una tale interfaccia e ti rimangono due opzioni: o crea il livello di astrazione tu stesso, o vai dritto per l'approccio pull. L'adeguatezza in generale dipende dal tuo contesto reale e alcuni casi rari (vedi sopra) esistono, in cui il tuo unico modo possibile è quello di tirare.