Quale sarebbe il modo migliore per progettare una gigantesca classe di wrapper API con più "sezioni"?

Naviga le tue risposte
2

Ecco il problema che sto cercando di risolvere:

C'è un'API piuttosto grande Sto cercando di scrivere una classe wrapper in giro. L'approccio più semplice sarebbe quello di rendere una classe con un metodo che rappresenta ogni possibile chiamata API. Questo diventa poco maneggevole anche se l'API è molto grande.

Il mio primo pensiero è quello di suddividere ogni sezione API in una classe separata. Se questa fosse l'API di Github potrei avere una classe per l'API dell'utente e una classe per l'API di repository ecc. Comunque voglio che l'interfaccia finale sia accessibile da un namespace come questo (questo è in Python): 

from my_api import APIClient

api = APIClient(api_token)

api.users_api_call()
api.repositories_api_call()

Come dovrei ottenere questo? All'inizio l'ereditarietà multipla sembrava una buona opzione, ma non sono sicuro di come accedere a cose come un token API e altre proprietà / funzioni generali nelle classi specializzate, inoltre la saggezza convenzionale suggerisce che l'MI sia una scelta di design scadente. Quali sono alcuni approcci da considerare qui?

    
posta Spencer Wood 27.07.2016 - 18:17
fonte

3 risposte

1

Questo è abbastanza comune, almeno nelle API con cui ho a che fare.

In primo luogo, dovresti creare una classe per ogni componente logico della tua API: utenti, transazioni, tweet, ecc.. Vi raccomando di mettere una buona quantità di pensiero in questo. Un'organizzazione chiara è strumentale per un'API utilizzabile. Devi rendere pubbliche tutte queste classi, in modo che gli utenti possano importare questi componenti singolarmente.

Se decidi che devi avere una singola classe per gestire tutte le richieste API, basta creare una classe wrapper API (scegliere un nome migliore ovviamente) che manterrà le maniglie su tutte le altre classi. Quindi puoi fare: 

my_api = API(api_token)
my_api.users.get_users()

Se vuoi fare un ulteriore passo avanti, puoi persino creare metodi di inoltro come 

def get_users():
    users.get_users()

così i tuoi utenti possono salvare alcune sequenze di tasti.

    
risposta data 26.09.2016 - 04:10
fonte
2

Dato che questo è specifico per Python, puoi avere il meglio di entrambi i mondi: un pacchetto che divide la tua API in pezzi gestibili ed evita l'oggetto-dio e ha una singola importazione. La soluzione? I pacchetti Python hanno tipicamente un file init .py, che può essere usato come il pacchetto importa le cose e le presenta al mondo esterno.

Esempio: 

package\
__init__.py
moduleA.py
moduleB.py

in __ init __. py: 

__all__ = [ 'moduleA', 'moduleB']

now you should be able to import them directly using import package.

Vedi questo post per ulteriori informazioni: link

    
risposta data 26.09.2016 - 08:01
fonte
0

Quello che stai cercando di fare è il Pattern di facciata , ma provando a racchiudere tutte le API giganti che sei incorrendo nell'oggetto God antipattern.

Gli oggetti di Dio violano il principio di responsabilità singola e principio di segregazione dell'interfaccia e rende difficile rispettare il principio Aperto / Chiuso .

Non so quale lingua stai usando, ma alcuni linguaggi supportano pacchetti (una sorta di spazio dei nomi) in modo da poter importare più classi contemporaneamente: 

import com.apifacade.*;

Il mio consiglio è di modellare classi diverse con preoccupazioni specifiche come nell'esempio che tu dai: Utente, RepositoryList, Repository, ecc. In questo modo avrai meno problemi di dipendenza.

    
risposta data 27.07.2016 - 19:12
fonte

Leggi altre domande sui tag

Modellazione del modello di disegno composito Learning PHP: creazione di una classe password