Motivo di progettazione: chiamata di funzione statica con contenitori di input / output?

Question

Motivo di progettazione: chiamata di funzione statica con contenitori di input / output?

#1 da (2 voti)

1

Lavoro per un'azienda nel reparto di ricerca software. Utilizziamo algoritmi dal nostro software reale e li avvolgiamo in modo da poterli utilizzare per la prototipazione. Ogni volta che cambia l'interfaccia dell'algoritmo, dobbiamo adattare i nostri wrapper rispettivamente.

Recentemente tutti gli algoritmi sono stati refactored in modo tale che invece di accettare molti input diversi e restituire output tramite parametri di riferimento, accettano ora un contenitore di dati di input e un contenitore di dati di output (quest'ultimo viene passato per riferimento). L'interfaccia dell'algoritmo è limitata a una chiamata di una funzione statica del tipo:

class MyAlgorithm{
static bool calculate(MyAlgorithmInput input, MyAlgorithmOutput &output);
}

Questo è in realtà un progetto molto potente, sebbene non l'abbia mai visto prima in un ambiente di programmazione C ++. Le modifiche al numero di parametri e ai loro tipi di dati sono ora incapsulate e non cambiano il callback dell'algoritmo.

Nell'ultimo algoritmo che ho sviluppato ho usato lo stesso schema. Ora voglio sapere se questo è un modello di design popolare e come viene chiamato.

design-patterns

posta Pavlo Dyban 05.11.2013 - 16:21

fonte

1 risposta

Leggi altre domande sui tag design-patterns

Preelaborazione dell'input della rete neurale Come descrivere Importa un'azione di file nel diagramma Sequenza

score 2 · Accepted Answer

This is actually a very powerful design, though I have never seen it in a C++ programming environment

Penso che la parola potente sia aperta all'interpretazione, e in realtà dipende dalla prospettiva, concordando con Kilian Foth commenta, in ciò che definisce un anti-pattern .

La maggior parte dei progetti C ++ che vedrai sono probabilmente open source o aperti in un modo o nell'altro, quindi i moduli di licenza e le tecniche di offuscamento del codice saranno difficili da trovare.

Dopotutto, con la tecnica che hai descritto sacrificerai in qualche modo un significativo aiuto al codice IDE, che viene utilizzato da una sezione lorda di programmatori.

Questo tipo di involucro rende le cose più offuscate e immagino che parte della motivazione a farlo possa effettivamente essere la protezione della proprietà intellettuale, nonostante il leggero impatto sulle prestazioni dovuto alle operazioni extra di stack.

D'altra parte dipende dal linguaggio di programmazione e dalle sue idiosincrasie : In JavaScript, ad esempio, uso un tale "modello" per esempio per passare stringhe per riferimento.

In C ++ renderebbe un senso per test aggiuntivi su parametri, tipo, integrità, puntatore e limiti di memoria . Come tale prende una pagina da codice gestito meno la macchina virtuale dell'applicazione. Per favore, correggimi se sbaglio.

Potrei vedere questo tipo di wrapping utilizzato frequentemente nello sviluppo di un motore di gioco. La tua azienda è in qualche modo coinvolta in quel campo?