Implementazione di qualcosa in parte rispetto alla semplice documentazione?

Question

Implementazione di qualcosa in parte rispetto alla semplice documentazione?

#1 da (6 voti)
#2 da (2 voti)

1

Spesso incontro il seguente programma durante la programmazione. Esiste una soluzione "parziale" a un problema, che fornisce tutte le funzionalità necessarie, ma la documentazione che spiega tale funzionalità e il comportamento della soluzione è molto densa ed esoterica. Quindi, esiste una soluzione "completa", che fornisce più funzionalità del necessario, ma la documentazione non deve spiegare perché non funziona in alcuni casi, e quindi è molto semplice e facile da capire.

Proprio come un esempio immediato, considera un metodo Foo(A a) che prende un singolo argomento di tipo A . Diciamo solo che c'è un'implementazione facile di Foo , ma richiede A per avere determinate proprietà, e la spiegazione del motivo per cui tali proprietà sono necessarie è lunga e complessa.

La soluzione "parziale" è all'inizio di Foo Semplicemente controllo se A ha le proprietà richieste e poi lo rifiuta se non lo fa. Ciò, tuttavia, rende la documentazione molto complessa poiché ora devo spiegare perché non funziona per determinati oggetti.

D'altra parte ho la soluzione "completa", che è semplicemente rendere Foo lavoro per tutti A s, indipendentemente dalle loro proprietà. Supponiamo che potrebbe teoricamente implementare un Foo che lo comporti, ma richiede molto più codice rispetto all'implementazione "parziale".

Quale è meglio?

Forse è un cattivo esempio, ma mi imbatto spesso in generalizzazioni di questo problema in molti dei miei progetti più grandi. Quale soluzione dovrei scegliere di fronte a questo dilemma (se uno dei due "parziale" o "pieno")? Esistono suggerimenti generali per evitare che questa situazione si verifichi?

documentation

posta user3002473 19.04.2016 - 09:56

fonte

2 risposte

2

Molte volte, le persone hanno problemi come questo e pensano che sia un problema di progettazione con Foo o la sua classe di chiusura, ma in realtà è un problema di progettazione con A .

Ad esempio, supponiamo che A sia una connessione al database. Le precondizioni comuni sulle connessioni al database sono che puntano a un indirizzo IP valido, contengono informazioni di autenticazione valide, ecc. Se dovessi controllare ogni condizione su ogni chiamata di funzione, diventerebbe noioso, quindi un modello comune è quello di dividere la classe. Una classe che usi mentre inserisci l'indirizzo del server e le informazioni di autenticazione, quindi da quell'oggetto che convalidi le precondizioni una volta e crei un altro oggetto che viene utilizzato per l'esecuzione query.

In altre parole, invece di avere lo stesso oggetto in uno stato diverso, cerca opportunità crea un nuovo oggetto per uno stato diverso. Ciò semplifica sia il controllo delle precondizioni che la complessità complessiva.

Solitamente se le gerarchie di tipi sono progettate correttamente, le situazioni in cui devi scegliere un'implementazione pesantemente condizionata sono abbastanza rare. Se sta arrivando molto in una base di codice, il tempo necessario per ottenere i tuoi tipi in forma vale la pena.

risposta data 20.04.2016 - 02:23

fonte

Leggi altre domande sui tag documentation

Come marcare / tracciare le caratteristiche nel codice? Una variabile deve contenere un'istanza di una classe se richiama un metodo?

score 6 · Accepted Answer

Questo è davvero facile.

I tuoi requisiti indicano che hai bisogno di essere in grado di elaborare A s senza le proprietà limitanti? (Va bene, tutto è relativo, quindi ti chiedo: hai bisogno della capacità abbastanza male da pagare il tempo di sviluppo extra ?)

Se sì, quindi scrivi il codice aggiuntivo.

Se no, codifica la soluzione semplice con la precondizione più complicata.

Le precondizioni sulle API sono un trascinamento, ma se le si documenta non si tratta di aver fatto qualcosa in modo improprio. Le soluzioni eleganti sono belle, ma hanno un costo e ogni costo deve essere giustificato. "Mi scuso per aver scritto una lettera così lunga, ma mi è mancato il tempo di accorciarlo" può essere una valida scusa in ambito professionale.