È considerato Pythonic avere più classi definite nello stesso file?

26

Lavorando con python per la prima volta, ho scoperto che finisco per scrivere più classi nello stesso file, che si oppone ad altri linguaggi come Java, che usa un file per classe.

Di solito, queste classi sono composte da 1 classe base astratta, con 1-2 implementazioni concrete che l'uso varia leggermente. Ho pubblicato uno di questi file qui sotto:

class Logger(object):

    def __init__(self, path, fileName):
        self.logFile = open(path + '/' + filename, 'w+')
        self.logFile.seek(0, 2)

    def log(self, stringtoLog):
        self.logFile.write(stringToLog)

    def __del__(self):
        self.logFile.close()

class TestLogger(Logger):   

    def __init__(self, serialNumber):
        Logger.__init__('/tests/ModuleName', serialNumber):

    def readStatusLine(self):
        self.logFile.seek(0,0)
        statusLine = self.logFile.readLine()
        self.logFile.seek(0,2)
        return StatusLine

    def modifyStatusLine(self, newStatusLine):
        self.logFile.seek(0,0)
        self.logFile.write(newStatusLine)
        self.logFile.seek(0,2)

class GenericLogger(Logger):

    def __init__(self, fileName):
        Logger.__init__('/tests/GPIO', fileName):

    def logGPIOError(self, errorCode):
        self.logFile.write(str(errorCode))

Come visto sopra, ho una classe base di Logger, con un paio di differenze di implementazione al di sotto di questo.

La domanda: Questo standard è per Python o per qualsiasi lingua? Quali problemi potrebbero sorgere dall'usare questa implementazione, se esiste?

EDIT: non cerco davvero indicazioni su questo file specifico , ma in un senso più generale. Che cosa succede se le classi hanno finito per essere 3-5 metodi moderatamente complessi? Avrebbe senso dividerli allora? Dov'è il limite per dire che dovresti dividere un file?

    
posta Ampt 30.08.2013 - 17:03
fonte

5 risposte

19

Va bene. Va bene anche in C ++, per riferimento.

Tenere insieme le cose strettamente accoppiate è una pratica ragionevole. Evitare accoppiamenti inappropriati è anche una buona pratica. Trovare il giusto equilibrio non è una questione di regole rigide, ma di un equilibrio tra preoccupazioni diverse.

Alcune regole pratiche:

  1. Dimensioni

    File troppo grandi possono essere brutti, ma non è questo il caso. La bruttezza è probabilmente una ragione sufficiente per dividere un file, ma lo sviluppo di quel senso estetico è in gran parte una questione di esperienza, quindi non aiuta a capire cosa fare a priori

  2. Separazione delle preoccupazioni

    Se le tue implementazioni concrete hanno preoccupazioni interne molto diverse, il tuo singolo file accumula tutte queste preoccupazioni. Ad esempio, le implementazioni con dipendenze non sovrapposte rendono il tuo singolo file dipendente dall'unione di tutte quelle dipendenze.

    Quindi, a volte può essere ragionevole considerare che l'accoppiamento delle sottoclassi alle loro dipendenze superi il loro accoppiamento con l'interfaccia (o viceversa, la preoccupazione di implementare un'interfaccia è più debole delle preoccupazioni interne a tale implementazione).

    Come esempio specifico, prendi un'interfaccia generica per il database. Le implementazioni concrete che utilizzano rispettivamente un DB in memoria, un RDBMS SQL e una query Web potrebbero non avere nulla in comune a parte l'interfaccia e forzare chiunque desideri che la versione in-memory leggera importerà anche una libreria SQL è sgradevole.

  3. L'incapsulamento

    Anche se puoi scrivere classi ben incapsulate nello stesso modulo, potrebbe incoraggiare l'accoppiamento non necessario solo perché hai accesso a dettagli di implementazione che altrimenti non verrebbero esportati al di fuori del modulo.

    Penso che sia solo un cattivo stile, ma potresti rafforzare la disciplina suddividendo il modulo se davvero non puoi rompere l'abitudine.

risposta data 30.08.2013 - 17:24
fonte
6

I miei soliti documenti di riferimento per sapere cos'è Pythonic.

Simple is better than complex.

Flat is better than nested.

Da The Zen Of Python

Almost without exception, class names use the CapWords convention.

Package and Module Names Modules should have short, all-lowercase names. [...] Module names are mapped to file names

Da PEP 8

La mia interpretazione è che va bene perché manterrebbe le cose semplici e piatte. Inoltre, poiché i nomi delle classi e i nomi dei file hanno casi diversi, non dovrebbero essere identici in ogni caso, quindi non vedrei alcun problema nel confezionare più classi correlate in un file.

    
risposta data 30.08.2013 - 17:29
fonte
1

Quello che hai ora va bene. Vai e sfoglia la libreria standard - ci sono molti moduli con più classi correlate in un singolo file. A un certo punto, le cose si ingrandiscono e alla fine vorrai iniziare a usare moduli con più file ma non ci sono regole reali su quando. Le cose si dividono quando un file inizia a sentirsi "troppo grande".

    
risposta data 30.08.2013 - 21:55
fonte
0

Va decisamente bene e ti incoraggerei ad avere diverse classi in un unico file fintanto che sono state realizzate. In generale, le tue lezioni dovrebbero rimanere brevi e concise e dovresti piuttosto dividere il comportamento in due o più classi piuttosto che costruire enormi monolitici. Quando scrivi diverse classi piccole è davvero necessario e utile mantenere quelli che sono collegati nello stesso file.

    
risposta data 01.07.2014 - 22:29
fonte
-2

In breve - diavolo si.

Inoltre, avere più classi in un singolo file è a volte molto utile. Alcuni pacchetti ( six , bottle ) vengono spediti esplicitamente in un singolo file per essere facilmente integrati in qualsiasi modulo di terze parti senza essere installati su pip (a volte desiderabili). Ma assicurati di organizzare bene il tuo codice. Utilizza in modo intensivo commenti di codice e blocchi di separazione per renderlo più leggibile.

    
risposta data 01.07.2014 - 17:39
fonte

Leggi altre domande sui tag