Code-Designfrage für (m)ein Programm

[maces]

Hi Forum,

Ich habe eine Frage zum "Design" eines Programms. Ich schreibe momentan ein umfangreiches Backup- und Synchronisierungsprogramm mit Python. Die erste Funktionsfähige Version wird so um die 500-1000 Zeilen Code haben (momentan noch 200). Jetzt frage ich mich ob es Sinn macht, die einzelnen Klassen in separate Dateien unterzubringen, oder alles in eine Datei schreibe (siehe Abbildungen). Abgebildet sind nur ein Teil der Klassen, es sind im Moment 8, vor allem die Klasse "db" wird oft gebraucht, da sie die Daten der verschiedenen Festplatten verwaltet.

Prinzip 1, Alles in einer Datei:
+ keine komplizierten Verschachtelungen.
- je größer das Programm um so schwieriger ist der Code zu lesen.
"UML":

Groß

Prinzip 2, Alles in separate Dateien (dezentral):
Die einzelnen Klassen(settings) includieren die benötigten Klassen(db) und geben das Endergebnis an die Klasse Interactive zurück.
+ einfach
+ kleinere (überschaubare) Dateien
- evtl. wird es unübersichtlich

Code zum includieren:

Code: Alles auswählen

class settings:
    def add(self):
        import settings
        settings.settings().add()

"UML":

Groß

Prinzip 3, Alles in separate Dateien (zentral):
Die einzelnen Klassen(settings) fordern die benötigten Informationen (zum Beispiel aus der db) von der Hauptklasse(interactive), diese includiert die benötigte Klasse(db) und ermittelt die benötigten Informationen. Diese werden anschließend an die ursprüngliche Klasse(settings) weitergegeben.
+ Man muss nur die Hauptdatei bearbeiten, um den Informationsfluss zu verändern.
+ kleinere (überschaubare) Dateien
- sehr kompliziert
- es wird eine extra Klasse für die Verwaltung der Anfragen benötigt
"UML":

Groß

Momentan favorisiere ich Prinzip 2, allerdings weiß ich nicht wie komplex das Programm werden wird, da es mein erstes Programm dieser Größe ist. Nun meine Frage an euch, welchen Ansatz haltet ihr (Designtechnisch) für die beste/eleganteste bzw am besten nachvollziehbare Lösung. Der Code sollte ja schließlich nicht nur von mir verstanden werden können .

maces

PS: Wenn ihr mehr Informationen benötigt, sagt bescheid.

[BlackJack]

@maces: Mich verwirrt die Terminologie ein bisschen. In Python wird nichts "includiert", ``import`` ist etwas anderes als ``include`` bei C oder PHP.

Fang doch einfach mit einem Modul an, und wenn es zu gross wird, kannst Du anfangen Dir zu überlegen, welche Klassen und Funktionen in eigene Module ausgelagert werden können oder sollten.

Dein Quelltextschnippsel macht mir Angst. Was soll das denn semantisch bedeuten was da passiert? Was ist `settings.settings`? Eine Klasse? Falls ja, bitte die Klasse in "CamelCase" benennen. Warum wird davon ein Exemplar erstellt, die `add()`-Methode aufgerufen und das Exemplar dann wieder verworfen? Das riecht komisch.

Importe sollten IMHO in der Regel an den Anfang eines Moduls. So sieht man einfacher zu welchen anderen Modulen Abhängigkeiten bestehen. In tieferen Ebenen zu importieren macht manchmal Sinn, wenn der Import nur in ganz seltenen Ausnahmefällen überhaupt stattfindet und/oder wenn er besonders "teuer" ist, weil da viele weitere Importe dran hängen oder längere Berechnungen durch den Import ausgeführt werden. Ist aber bei diesem Szenario alles scheinbar nicht gegeben.

[maces]

Hi BlackJack

Erstmal Danke für die schnelle Antwort

@maces: Mich verwirrt die Terminologie ein bisschen. In Python wird nichts "includiert", ``import`` ist etwas anderes als ``include`` bei C oder PHP.

eigentlich meinte ich import

Fang doch einfach mit einem Modul an, und wenn es zu gross wird, kannst Du anfangen Dir zu überlegen, welche Klassen und Funktionen in eigene Module ausgelagert werden können oder sollten.

So ähnlich hatte ich es vor. Ich wollte nur wissen, was eleganter wäre.

Dein Quelltextschnippsel macht mir Angst. Was soll das denn semantisch bedeuten was da passiert? Was ist `settings.settings`? Eine Klasse? Falls ja, bitte die Klasse in "CamelCase" benennen. Warum wird davon ein Exemplar erstellt, die `add()`-Methode aufgerufen und das Exemplar dann wieder verworfen? Das riecht komisch.

Stimmt, der Quelltextschnippsel sagt ohne den Rest des Codes wenig aus. Es passiert folgendes: Die Datei/Modul "settings" wird importiert. In der Datei "settings" gibt es eine Klasse "settings", die die Funktion "add()" beinhaltet. Ich werde den Teil umschreiben, sodass es verständlicher wird.

Importe sollten IMHO in der Regel an den Anfang eines Moduls. So sieht man einfacher zu welchen anderen Modulen Abhängigkeiten bestehen. In tieferen Ebenen zu importieren macht manchmal Sinn, wenn der Import nur in ganz seltenen Ausnahmefällen überhaupt stattfindet und/oder wenn er besonders "teuer" ist, weil da viele weitere Importe dran hängen oder längere Berechnungen durch den Import ausgeführt werden. Ist aber bei diesem Szenario alles scheinbar nicht gegeben.

Okay also die importe zum Anfang jedes Moduls ausführen.

Zusammengefasst heißt das Code aufräumen (importe, CamelCase). Klassen in der "Haupt"-datei lassen und nur wenn sie zu groß werden auslagern (Prinzip1+2).
btw: Ich hatte mal im Wiki einen Leitfaden für guten Code gefunden, allerdings finde ich ihn nicht mehr, kennt jemand dafür eine Doku?

maces

[Hyperion]

btw: Ich hatte mal im Wiki einen Leitfaden für guten Code gefunden, allerdings finde ich ihn nicht mehr, kennt jemand dafür eine Doku?

maces

Meinst Du PEP8?

[DasIch]

btw: Ich hatte mal im Wiki einen Leitfaden für guten Code gefunden, allerdings finde ich ihn nicht mehr, kennt jemand dafür eine Doku?

PEP 8

[maces]

@ Hyperion, DasIch:
Danke genau das habe ich gesucht.

maces