Design pattern name per una classe wrapper API [chiusa]

Il modello dell'adattatore avrà lo stesso nome del metodo. X.DoSomething () farà cose diverse quando si applica a oggetti diversi.

Il modello di facciata accede a diverse funzioni in classi diverse separate. Esempio di classe di facciata dovrebbe essere quando si desidera creare una classe di validazione.

La mia ipotesi è che potrebbe essere il pattern Observer, poiché quando l'oggetto cambia, un altro oggetto dipendente cambia automaticamente. Sei consapevole del fatto che MVC è un modello di Osservatore, vero?

Altrimenti, può anche essere il modello di Mediatore. Quindi, quando il tuo oggetto nel sistema interno vuole parlare con l'oggetto API GitHub, dovrà accedere alla tua classe per accedere.

Grazie,

Ci sono due nomi comuni:

Entreprise Integration Pattern

o

Enterprise Service Bus

Ecco alcuni esempi di modelli EIP / ESB

Stai facendo uso della delega. Cioè stai delegando GitHub :: fetchUser () all'API GitHub. Quindi lo chiamerei un "delegato".

Alcuni suggerimenti alternativi perché a volte le cose devono essere "corrette"

Potrebbe essere considerato un ClientProxy . Dipende da come verranno confezionate le cose. Questo diventerà una DLL autonoma? Se è così, è probabilmente un proxy client.

Forse è solo una classe convenienza di un'applicazione più grande (es. lascia la porta aperta ad un uso più avanzato)? Se è così, potrebbe essere un " Helper " (anche se non mi piace il termine) - un " Utility " è migliore. Meglio sarebbe ancora un " StreamlinedClient " - " Facile " o " Semplice " troppo poco professionale, ma se combinato con "Interfaccia" possono suono ragionevole: " SimplifiedInterface "

Ora, se questo wrapper ha lo scopo di nascondere l'implementazione avanzata in modo tale che la tua applicazione userà il tuo wrapper solo quando si interfaccia con l'API esterna ... è semplicemente un servizio o ServiceWrapper .

Facciata è sovrautilizzato (specialmente in Java): e la tua descrizione semplificata si adatta; tuttavia, tendo a pensare a questo solo quando si incapsula senza aggiungere molto in termini di logica (una sorta di flusso di lavoro che non è realmente correlato al problema da risolvere).