Utilizzo di un SDK con codice pazzo

6

Recentemente ho dovuto lavorare con un SDK che aveva un sacco di parti pazzesche *. Non usare l'SDK non era un'opzione in quanto doveva parlare con alcuni software di terze parti.

Qual è il modo migliore per gestire il codice pazzo? Generalmente ho utilizzato metodi statici per convertire i tipi di dati sensibili nel formato richiesto (ad esempio bool in yesNo). Questo metodo ha tuttavia portato a un sacco di chiamate a metodi statici molto non ingegnosi (quale dei tre metodi dateToString dovrebbe essere chiamato dove?)

Sarebbe un approccio migliore memorizzare quasi tutto come una stringa nel database? O eventualmente convertire ogni tipo di dati in linea in modo che sia chiaro (anche se con codice ripetuto). Forse c'è qualche altra soluzione elegante che non avevo pensato?

* Alcuni metodi richiedevano un enum chiamato yesNo che conteneva "Yes", "y", "No" e "n". C'erano anche diversi formati di stringa differenti che volevano rappresentare i dati utilizzati in modo incoerente. C'erano anche altri piccoli pezzi di codice pazzo.

    
posta Tom Squires 30.09.2011 - 14:15
fonte

4 risposte

6

Sembra un uso appropriato di il modello dell'adattatore . Potresti passare i tuoi "dati sani" e fare chiamate ai metodi più appropriati. Se volessi astrarre alcune chiamate per semplificare l'interfaccia, piuttosto che semplicemente trasformarla, sarebbe un uso appropriato di il modello di facciata .

    
risposta data 30.09.2011 - 14:25
fonte
5

Se la dimensione dell'API è sufficientemente piccola (ovvero è piuttosto piccola o è di medie dimensioni, ma la userai per anni), potresti scrivere un wrapper adeguato per l'API con un'interfaccia ragionevole .

vale a dire. puoi scrivere il wrapper in modo che non sia necessario chiamare un metodo single dell'API originale per utilizzarlo.

Questo approccio ha un ulteriore vantaggio se puoi rendere il tuo wrapper "distorto" (cioè ogni volta che esegui il frobming di un foo tu devi frobnicare la barra pure) o "converti" tra paradigma (ad esempio producendo un OO-wrapper attorno ad alcune API non OO).

È che implicherà uno sforzo significativo, quindi assicurati che ne valga la pena prima.

    
risposta data 30.09.2011 - 14:23
fonte
1

Cercare di fare il minimo indispensabile per convertire i tipi di dati sta diventando più doloroso. Scrivi l'API come desideri e implementalo come un wrapper per loro. È un po 'più in fase di digitazione, ma molto meno lavoro in generale.

    
risposta data 30.09.2011 - 14:22
fonte
1

Data la natura del problema, prenderemo in considerazione Livello anticorruzione .

...it is likely that... you are inevitably faced with the task of interacting with the spaghetti that is already there. Enter the Anti-Corruption Layer. (Anatomy of an Anti-Corruption Layer, Part 1)

    
risposta data 30.09.2011 - 17:52
fonte

Leggi altre domande sui tag