Python - quando una classe dovrebbe avere - piuttosto che essere-a?

1

Questo è legato a "Estendi è il male" rispetto a OCP? ma separato perché l'idea di "implementare l'interfaccia" non esiste in Python.

Sto scrivendo un corso per estrarre alcuni dati da una pagina web. Avrà bisogno di conservare un cookie per l'autenticazione, quindi userò un oggetto requests.Session in qualche modo. Non sono mai sicuro di come affrontare questo - qual è la scelta appropriata qui?

class FooFetcher(requests.Session):
    def __init__(self):
        super.__init__()

o

class FooFetcher(object):
    def __init__(self):
        self.session = requests.Session()

Il primo sembra finire con FooFetcher che ha molto più metodi pubblici del necessario. Quest'ultima sembra che potrebbe essere inutilmente complicata, dal momento che praticamente ogni metodo di FooFetcher coinvolgerà una chiamata a un metodo di quell'oggetto Session , più forse un po 'di analisi di JSON che trova.

    
posta Patrick Collins 13.09.2013 - 20:56
fonte

2 risposte

3

Il trucco è guardare il codice chiamante . Esiste un codice che attualmente utilizza un oggetto requests.Session che desideri essere in grado di passare in FooFetcher ? In caso contrario, quindi utilizzare la composizione.

    
risposta data 13.09.2013 - 21:02
fonte
1

Il tuo particolare esempio suggerisce strongmente la relazione HAS-A, quindi, composizione, perché FooFetcher non è una sessione.

BTW, Python ha ereditarietà multipla, e talvolta è possibile aggiungere funzionalità usando i mix-in.

Ad esempio, potresti avere Session e aggiungerlo come mix-in:

 class FooFetcher(BaseFetcher, Sessioning):
     ...

Ritornando al tuo secondo esempio, penso che la sessione dovrebbe essere esplicita:

class FooFetcher(object):
    def __init__(self, session):
        self.session = session

In questo modo è più facile testare e mantenere il codice.

    
risposta data 13.09.2013 - 22:37
fonte

Leggi altre domande sui tag