Razionale dietro il proprio livello di fronte all'API standard

1

Ho visto pochi progetti in cui l'accesso a molte funzioni specifiche del sistema è stato inserito nel livello intermedio specifico del progetto. Gli esempi includono funzioni per la registrazione (avvolto attorno a Log4J), file IO (metodi come scrivere contenuto nel file, rilevare IOException), accesso alle risorse, utilizzo di proprietà e cose simili. La maggior parte dei metodi in questo strato di reindirizzamento aveva un codice molto piccolo. Il team ha utilizzato la revisione del codice per imporre a tutti di chiamare questo livello helper, indipendentemente dal fatto che lo vedano utile o meno.

Gli argomenti per l'utilizzo di questo livello erano che "potremmo aggiungere il codice standard ad ogni azione di questo tipo", "l'API potrebbe cambiare, il nostro livello rimarrà" e che "molti sviluppatori non sono abbastanza competenti (in caso di usando lo strato attorno a Hibernate) ". Forse anche che qualche codice può essere riutilizzato.

Gli svantaggi possono essere che la libreria di livelli è un pezzo di codice per mantenersi, anche gli sviluppatori competenti devono impararlo prima quando vengono assunti e i giovani sviluppatori apprendono alcune API che non troveranno da nessun'altra parte, piuttosto che imparare cose standard e che potrebbe limitare le possibilità disponibili sull'API che avvolge.

Questa libreria di livelli è un approccio raccomandato o anti-pattern?

    
posta h22 17.07.2017 - 11:54
fonte

2 risposte

4

Uno dei motivi principali per farlo è in effetti nascondere la complessità o proteggere il modello di sistema dalla corruzione. Ma c'è un altro vantaggio che diventa più importante nel tempo: manutenibilità.

Se usi servizi importanti di un modulo di terze parti, spesso li usi in più di un posto. Supponiamo che ci siano 5 punti di accesso alla biblioteca e li utilizzi in media tre volte: 14 chiamate in tutto. Ora quando la libreria di terze parti cambia la sua interfaccia, devi cambiare il tuo codice in 14 luoghi. Se avessi nascosto quella libreria, dovresti solo cambiare 5 posizioni e tutte quelle modifiche sono limitate al livello di adattamento .

Ciò significa che la manutenzione futura di questo aspetto della tua app può essere eseguita da uno specialista (ad esempio un op di database per un driver di database o un esperto di matematica per un pacchetto di analisi statistica) che non ha bisogno di alcuna conoscenza del tuo flusso di lavoro principale e, al contrario, nessuno dei tuoi sviluppatori aziendali ha bisogno di cambiare la affatto . La divisione del lavoro è l'unica idea incontestata che l'economia umana prospera e gli strati di adattamento consentono la divisione del lavoro.

    
risposta data 17.07.2017 - 12:25
fonte
1

Dalla risposta di riferimento e dai commenti che ho provato a raccogliere insieme, sembra che abbia senso avere il wrapping layer se:

  • Hai una visione di come le diverse API ti consentono molto meglio design rispetto all'API originale.
  • Il team API è noto per i frequenti ma minuscoli modifiche aggressive (metodo rinominato, ecc.) che possono essere corrette il livello dell'involucro.
  • L'utilizzo dell'API richiede molte revisioni (sensibile alla sicurezza, sensibile alle prestazioni, molto complesso o semplicemente bacato)
risposta data 17.07.2017 - 16:30
fonte

Leggi altre domande sui tag