Che cosa differenzia gli oggetti funzione dai poltergeist?

3

La versione abbreviata (originale)

In che modo gli oggetti funzione, a volte chiamati "funtori" in C ++ e in altri linguaggi OO, hanno senso diverso dalle classi sintomatiche dell'anti-pattern del poltergeist?

Definizioni

  • Un oggetto funzione è un costrutto che consente a un oggetto di essere invocato o chiamato come se fosse una funzione ordinaria ( definizione completa , seguono altri riferimenti).
  • Un poltergeist è un oggetto di breve durata, tipicamente stateless, che viene utilizzato esclusivamente per attivare o inizializzare diversi altri oggetti e quindi scartato. È considerata una conseguenza della progettazione di oggetti scadenti ( definizione completa , altri riferimenti seguono).

Perché chiedo?

In molti punti dell'ampia base di codice su cui sto lavorando, una struttura di dati complessa viene attraversata in diversi modi e su ogni elemento viene applicato. Per non violare il principio DRY riscrivendo il codice di attraversamento complesso e le sue varianti, ho invece diverse funzioni di attraversamento di ordine superiore che accettano gli oggetti funzione che agiscono sugli elementi come argomenti. Probabilmente, il pattern iteratore (C ++) è giustificato qui, ma mancava e la sua implementazione è costosa, quindi l'ho rimandata.

Avevo la preoccupazione che questi oggetti a funzioni multiple avrebbero offuscato il mio codice e reso meno mantenibile, ma invece di chiedere "questo rende il mio codice più oscuro", che sembra una domanda basata sull'opinione, quindi ho fatto allusione a più -o meno cose conosciute con definizioni concrete. Non capivo perché gli oggetti funzione non possono essere tutti classificati come poltergeist / design difettoso prima che la risposta fosse gentilmente fornita da Karl Bielefeldt.

Riferimenti aggiuntivi

Poltergeists:

In origine, questa domanda includeva anche questo articolo qui , che probabilmente significa che è anche nel libro Design Patterns Explained Simply , ma le persone [disclaimer] hanno contestato questo articolo nei commenti per ragioni apparentemente estranee al concetto attuale .

Funzioni oggetto:

Chiarimenti o di non rispondere a questa domanda

  • Questa domanda non riguarda né quanto sia noto il termine "anti-pattern del poltergeist", né se scoraggia o incoraggia le pratiche di codifica buone o cattive. Si prega di fare riferimento al articolo di Wikipedia sulle possibili confusioni su questo concetto.

  • Questa domanda non riguarda ciò che è e ciò che non è un funtore. Il termine "functor" significa cose diverse nel contesto della programmazione funzionale e del contesto dei linguaggi orientati agli oggetti. Questa domanda si riferisce agli oggetti funzione, ovvero la seconda definizione.

posta Greg Kramida 03.05.2018 - 16:58
fonte

2 risposte

9

Prima di tutto, fai attenzione a chiamarli funtori, perché apparentemente le persone C ++ hanno ignorato l'intera storia di ciò che functor significa e hanno deciso di ridefinire quel nome per i loro oggetti funzione, che è una cosa completamente diversa di quello che la maggior parte della gente pensa come un funtore.

In secondo luogo, l'anti-pattern poltergeist richiede di fare qualcosa di inaspettato tramite effetto collaterale. Se il tuo metodo operator() ha effetti collaterali, allora potrebbe certamente essere considerato un esempio di tale anti-pattern. Tuttavia, ci sono anche usi di operator() che non hanno effetti collaterali, come l'emulazione dell'applicazione per le funzioni parziali . Questi usi potrebbero potenzialmente avere altri anti-pattern, ma senza effetti collaterali inaspettati, non sarebbe un modello di poltergeist.

    
risposta data 03.05.2018 - 18:03
fonte
4

Oggetti molto semplici e potenzialmente di breve durata sono dannatamente utili in molti scenari; sì, quelli che erroneamente chiamano "funtori" (funzioni parzialmente applicate), tuple, opzioni, ecc. corrispondono a questo schema.

Se ci si preoccupa della massima efficienza e non si assegna mai un byte in più, si dovrebbe prima rilevare il percorso del codice caldo e ottimizzarlo. Per il resto del progetto (probabilmente il 99% di esso), tali ottimizzazioni non apportano alcun beneficio.

Tutto ciò che aiuta a pensare al programma più facilmente e chiaramente porta un vantaggio.

    
risposta data 03.05.2018 - 18:04
fonte