Apakah Pythonic dianggap memiliki beberapa kelas yang didefinisikan dalam file yang sama?

Dalam bekerja dengan python untuk pertama kalinya, saya menemukan bahwa saya akhirnya menulis beberapa kelas dalam file yang sama, yang bertentangan dengan bahasa lain seperti Java, yang menggunakan satu file per kelas.

Biasanya, kelas-kelas ini terdiri dari 1 kelas dasar abstrak, dengan 1-2 implementasi konkret yang penggunaannya sedikit berbeda. Saya telah memposting satu file seperti di bawah ini:

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))

Seperti yang terlihat di atas, saya memiliki kelas dasar Logger, dengan beberapa perbedaan implementasi di bawahnya.

Pertanyaan: Apakah standar ini untuk python, atau untuk bahasa apa pun? Masalah apa yang bisa timbul dari penggunaan implementasi ini jika ada?

EDIT: Saya tidak benar-benar mencari panduan tentang file spesifik ini , tetapi dalam pengertian yang lebih umum. Bagaimana jika kelas berakhir menjadi 3-5 metode yang cukup kompleks? Apakah masuk akal untuk membaginya? Di mana cutoff untuk mengatakan Anda harus membagi file?

Tidak apa-apa. Tidak masalah di C ++ juga, untuk referensi.

Menyatukan semua hal dengan erat adalah praktik yang masuk akal. Menghindari pemasangan yang tidak tepat juga merupakan praktik yang baik. Mencapai keseimbangan yang tepat bukanlah masalah aturan yang ketat, tetapi, yah, menyeimbangkan antara berbagai keprihatinan yang berbeda.

Beberapa aturan praktis:

1. Ukuran

   File yang terlalu besar bisa jelek, tapi itu tidak terjadi di sini. Kejahatan mungkin merupakan alasan yang cukup baik untuk membagi file, tetapi mengembangkan rasa estetika sebagian besar adalah masalah pengalaman, jadi itu tidak membantu Anda mencari tahu apa yang harus dilakukan apriori

2. Pemisahan Kekhawatiran

   Jika implementasi konkret Anda memiliki masalah internal yang sangat berbeda, file tunggal Anda mengakumulasi semua masalah tersebut. Misalnya, implementasi dengan dependensi yang tidak tumpang tindih membuat file tunggal Anda bergantung pada penyatuan semua dependensi tersebut.

   Jadi, kadang-kadang mungkin masuk akal untuk mempertimbangkan penggabungan sub-kelas terhadap dependensi mereka lebih besar daripada penggandaan mereka ke antarmuka (atau sebaliknya, masalah penerapan antarmuka lebih lemah daripada masalah internal untuk implementasi itu).

   Sebagai contoh spesifik, ambil antarmuka basis data generik. Implementasi konkret menggunakan DB dalam memori, RDBMS SQL, dan kueri web masing-masing mungkin tidak memiliki kesamaan selain dari antarmuka, dan memaksa semua orang yang ingin versi dalam memori yang ringan juga mengimpor perpustakaan SQL itu buruk.

3. Enkapsulasi

   Meskipun Anda dapat menulis kelas yang dienkapsulasi dengan baik dalam modul yang sama, itu dapat mendorong penggabungan yang tidak perlu hanya karena Anda memiliki akses ke detail implementasi yang tidak akan diekspor di luar modul.

   Ini hanya gaya yang buruk, tetapi Anda bisa menegakkan disiplin yang lebih baik dengan memisahkan modul jika Anda benar-benar tidak dapat menghentikan kebiasaan itu.

Dokumen referensi saya yang biasa untuk mengetahui apa itu pythonic.

Sederhana lebih baik daripada kompleks.

Flat lebih baik daripada bersarang.

Dari The Zen Of Python

Hampir tanpa kecuali, nama kelas menggunakan konvensi CapWords.

Nama Paket dan Modul Modul harus memiliki nama pendek, semua huruf kecil. [...] Nama modul dipetakan ke nama file

Dari PEP 8

Penafsiran saya adalah bahwa itu baik-baik saja karena itu akan menjaga hal-hal sederhana dan datar. Juga, karena nama kelas dan nama file memiliki kasus yang berbeda, mereka tidak seharusnya identik, jadi saya tidak akan melihat masalah dalam pengemasan beberapa kelas terkait dalam file.

Apa yang Anda miliki sekarang baik-baik saja. Buka dan telusuri pustaka standar - ada banyak modul dengan beberapa kelas terkait dalam satu file. Pada titik tertentu, segalanya menjadi lebih besar dan Anda akhirnya ingin mulai menggunakan modul dengan banyak file, tetapi tidak ada aturan nyata kapan. Berbagai hal baru saja terpecah ketika satu file mulai merasa 'terlalu besar'.

Sudah pasti oke dan saya akan mendorong Anda untuk memiliki beberapa kelas dalam satu file selama mereka direalisasikan. Secara umum, kelas Anda harus tetap singkat dan ringkas dan Anda sebaiknya membagi perilaku dalam dua kelas atau lebih daripada membangun kelas monolitik besar. Saat menulis beberapa kelas kecil, sangat penting dan bermanfaat untuk menjaga mereka yang terkait dalam file yang sama.

Singkatnya sih ya.

Selain itu, memiliki beberapa kelas dalam satu file terkadang sangat berguna. Beberapa paket ( six, bottle) secara eksplisit dikirimkan dalam satu file agar mudah diintegrasikan ke dalam modul pihak ketiga apa pun tanpa harus diinstal (kadang-kadang diinginkan). Tapi, pastikan untuk mengatur kode Anda dengan baik. Gunakan komentar kode dan blok pemisah secara intensif agar lebih mudah dibaca.