modulares Programmkonzept



  • Hallo,

    ich habe mir mal ein paar Gedanken zu folgendem gemacht:
    Nehmen wir an, ein Programm hat eine Oberfläche über die Daten eingegeben und abgerufen werden können. Intern wird dann mit diesen Daten gearbeitet. Die Daten werden aus einer Datenbank bezogen bzw. in diese geschrieben.
    Man könnte das ganze jetzt in einem Satz programmieren und fertig. Mich interessiert aber vielmehr, wie man das ganze etwas modularer gestalten kann.

    Erster Trennungspunkt wäre Oberfläche und Internes. Also eine Server/Client - Architektur. Der interne Teil ist der Server zu dem sich die Oberfläche als Client verbindet. Jetzt wäre es wünschenswert, wenn die Teile zur Kommunikation zwischen Client und Server leicht austauschbar wären. Beispielsweise könnte man die Kommunikation über Pipes regeln, wenn sowohl Client als auch Server auf dem selben System laufen. Wenn diese aber auf verschiedenen Rechnern sind und über das Netzwerk kommunizieren sollen, könnten man TCP/IP verwenden, mit oder ohne SSL oder was einem sonst noch so einfällt.
    Wäre es in dem Fall sinnvoll, den Teil zur Kommunikation in eine dynamiche Bibliothek auszulagern, so dass man nach Bedarf die eine oder andere Bibliothek zur Kommunikation nutzen kann? (Man könnte ja über eine Konfigurationsdatei festlegen, welche Bibliothek geladen werden soll. Es müssten nur die Schnittstellen der verschiedenen Bibliotheken gleich sein.) Oder gibt es da bessere Methoden?

    Ähnliches gilt für die Kommunikation des Servers mit der Datenbank. Ist es sinnvoll, diese in eine dynamische Bibliothek auslagern, damit man einfach die Möglichkeit hat eine andere zu verwenden, die z.B. eine andere Datenbank anspricht oder eine Datenbank die nur über das Netzwerk erreichbar ist und sich zusätzlich um den Verbindungsaufbau kümmert?

    Und ein weiterer Punkt wäre das Passwort für den Datenbankzugriff. Wie speichert man das am besten für das Programm ab? Einfach in eine Konfigurationsdatei schreiben aus der es ausgelesen wird? Dann sollte man den Server evtl. nicht unter dem Benutzernamen des Client-Users laufen, da dieser sonst Zugriff auf die Datei und damit auf das Passwort hätte. Oder gibt es da andere Möglichkeiten? (Außer es beim Start des Servers per Hand einzugeben.)

    Liege ich mit meinen Überlegungen soweit richtig oder vielleicht auch völlig daneben? Ist das Konzept sinnvoll? Was sollte/könnte man ändern?
    Ich wusste leider nicht genau, nach was ich da im Internet hätte suchen sollen, wenn daher jemand den Vorschlag hat doch einfach eine Suchmaschine zu bemühen, dann wäre es nett, die entsprechenden Suchworte mitzuliefern 🙂

    Gruß
    Abadetaba



  • Bei einem Modularen Programm kann dir eine OO Sprache eine ganze menge Arbeit abnehemen, für den beschriebenen Fall sind Interfaces, Abstrakte Klassen, Verebung, dynamische Typisierung gut geeignet.
    Sodass du deine Schnittstelle für jede Kommunikationsform Implementierst und dann jeweils die passende Klasse instanziierst.
    Das kannst du zB auch mit Funktionszeigern erreichen.

    Wichtig ist das eine gemeinsame Schnittstelle für alle Implementierungen definiert ist, dadurch wird das darunterliegende Abstrahiert (siehe Bibliotheken).

    Modularisierung ist eine gutes Konzept dadurch kannst du dein Programm einfach erweitern (zB weitere Datenbanken nutzen), und wenn irgendeiner meint er müsste mal wieder seine api ändern dann brauchst du nicht alles neu schreiben.



  • Verstehe ich das soweit richtig? ->
    Ich schreibe z.B. für den Datenbankzugriff für jede Datenbank eine Klasse die den Zugriff auf diese regelt. Die Schnittstellen nach außen müssen natürlich gleich sein.
    Wenn das ganze dann später kompiliert wird, werden alle Klassen für Datenbankzugriffe in das Programm mit hineinkompiliert. Über eine beliebige Konfigurationsmöglichkeit des Programms kann dann zwischen den einzelnen Datenbanken gewählt werden, was intern z.B. über Funktionszeiger realisiert werden kann, welche dann auf die entsprechende Klasse bzw. Funktion verweisen.

    Daran hatte ich auch erst gedacht. Dann war ich zu dem Punkt gekommen, dass man das ganze Programm ja erneut übersetzen müsste, wenn man eine neue Klasse für den Zugriff auf eine neue Datenbank erstellt hätte. Darüber war ich dann zu dynamischen Bibliotheken gekommen, wodurch man nur die neue Klasse übersetzen müsste.
    Aber nachdem ich deinen Beitrag gelesen habe, denke ich, dass es vermutlich selbst bei der Verwendung von dynamischen Bibliotheken sinnvoller wäre, alle Klassen für Datenbankzugriffe in einer Bibliothek zusammenzufassen, als n einzelne zu erstellen. Oder?

    Ich frage mich halt, was am meisten Sinn macht. Was aber vermutlich auch vom erwarteten Endergebnis abhängt ...



  • Es ist einbisschen wirr, was du schreibst. Du erwähnst zumindest viele wichtige Begriffe, sodass ich nicht davon ausgehen kann, dass du keine Ahnung hast. Dann versteifst du dich aber auf irgendwelche unwichtigen Punkte wie "dynamische Bibliothek" oder "Passwort speichern".

    Was ist für dich eine "dynamische Bibliothek"? Wenn du nicht neukompilieren willst, kannst du eine Pluginschnittstelle definieren, ist an sich kein Problem. Ich würde mich da aber schon fragen, ob es bei der Kommunikation Sinn macht. Eher weniger. Es reicht, wenn das intern in deinem Programm entsprechend modular aufgebaut ist, sodass du später vielleicht ein anderes Kommunikationsframework verwenden kannst, ohne den eigentlichen Code zu ändern. Das ist viel wichtiger, als den Kommunikationsmechanismus ohne Neukompilieren auszutauschen, sowas ist extrem selten wirklich nötig.

    Natürlich ist modularer Aufbau sehr wichtig. Aber ich kann deine diebezüglichen Überlegungen noch nicht wirklich nachvollziehen. Selbstverständlich trennt man Daten und Darstellung. Da gehts auch noch nicht um Client-Server, sondern da würde eher MVC oder MVP als Begriff passen. Client und Server zu trennen ist dann ein weiterer konzeptioneller Schritt. Kann Sinn machen, muss aber nicht. Kannst aber auf jeden Fall in deine Überlegungen miteinbeziehen. Was heute noch keinen Sinn macht, kann morgen vielleicht eine Prio 1 Anforderung werden.
    Generell solltest du, wenn du dir schon solche Gedanken machst (was ich absolut positiv finde), die gängigen Design und Architektur Patterns kennen. Wenn man sie kennt und ein Gefühl dafür entwickelt hat, denkt man beim Entwurf seiner Software schon etwas geordneter und kann sich viele Komponenten und deren Integration schon grob vorstellen.



  • Ja, kann sein, dass mein Geschreibsel ein wenig wirr ist. Liegt wohl daran, wie du richtig erkannt hast, dass ich durchaus nicht ahnungslos bin, es mir allerdings am Wissen mangelt, wie man all das sinnvoll vereinigt.
    Wie in meinem ersten Beitrag erwähnt, wusste ich auch nicht genau nach was ich suchen muss, um zu dem Thema etwas zu finden.

    Ich habe einen kurzen Blick auf die Wikipediaartikel zu MVC und MVP geworfen. Sieht interessant aus und werde ich mir später auf jeden Fall genauer anschauen.
    Und danke für den Hinweis auf die Design und Architektur Patterns. Werde mal schauen was ich dazu finden kann. Gibt es, abgesehen von MVC und MVP, bestimmte Muster die ich mir anschauen sollte?



  • Es gibt mehrere Ebenen von diesen Pattern Geschichten. Es gibt die Design Patterns, das sind sozusagen die Low Level Muster, auf die man beim Programmieren trifft, und wenn man die entsprechenden Muster kennt, dann erkennt man oft, dass sie bei einem bestimmten Problem, das man grad hat, helfen könnten. Wenn man sie nicht kennt, kommen oft ganz abenteuerliche Konstrukte raus. Aber das hilft dir natürlich noch nicht bei dem Gesamtkonzept und bei der Integration der Komponenten.
    Hier gibt es Architektur Patterns und Integration Patterns und übergeordnete Konzepte wie DDD oder SOA, wobei man sie natürlich auch als Patterns sehen könnte. Die anzuwenden ist vielleicht etwas schwieriger, weil sie größere Probleme auf einer recht abstrakten Ebene beschreiben und eher etwas sind, woran man sich orientiert, als etwas, was man direkt befolgen könnte.
    Kennen muss man natürlich alle 😉 Man kann nicht von vornherein sagen, ich kenne A und B und baue nach deren Prinzipien meine Software auf. Je mehr man kennt, desto klarer wird die eigene Vorstellung davon, wie man die Architektur der Software angehen könnte.
    Gut, MVC ist in der Hinsicht natürlich schon wichtig, gibt schon welche, die man ganz selten braucht, z.B. Blackboard. Lies dir am besten einfach mal paar Bücher dazu durch. Bücher sind hier besser, als irgendwelche Internetartikel. Ein Artikel mag ein konkretes Thema/Pattern gut erklären, aber ein Buch kann darüber hinaus noch das Gesamtkonzept noch etwas besser beleuchten.



  • Das es einiges an Pattern gibt, wusste ich, dass es aber so umfangreich ist, dann doch nicht.
    Gibt es Bücher die du mir empfehlen könntest? Denn Bücher zu dem Thema gibt es sicher viele, die guten werden aber vermutlich nur ein Bruchteil dessen sein.

    Natürlich hast du Recht, dass man alle Muster kennen sollte und sich nicht für alle Programme auf die selben paar Muster stützen kann. Mit meiner Frage nach bestimmten Mustern die ich mir anschauen sollte, meinte ich welche die mehr oder weniger unumgänglich sind, da man häufig auf sie zurückgreift. Aber mir einen Überblick über möglichst viele zu verschaffen ist wohl noch besser 🙂



  • Abadetaba schrieb:

    Das es einiges an Pattern gibt, wusste ich, dass es aber so umfangreich ist, dann doch nicht.

    Das kommt daher, dass es schon sehr viele sehr große Programme gibt, und das nicht erst seit gestern und sich einige Leute schon einige Gedanken dazu gemacht haben. Kann ja eigentlich auch nicht anders sein. Und es ist auch ganz nützlich, das alles zu kennen. Dann kann man vielleicht auch seine eigene Meinung bilden und sagen, das Konzept oder Pattern gefällt mir nicht, finde ich schlecht/falsch/was auch immer. Aber ohne zu wissen, was sich andere schon dazu gedacht haben, hat man eigentlich fast keine Chance, ein guter Entwickler zu werden. Das ganze Informatikstudium hat schon seinen Sinn 😉

    Die Bücher von Martin Fowler sind recht lesenswert. Das "Patterns of Enterprise Application Architecture" ist zwar nicht mehr ganz so aktuell und teilweise überholt. Aber das ist eben auch deswegen überholt, weil es eine Diskussion mitangestoßen hat, aus der dann teilweise bessere Ideen hervorgegangen sind, z.B. Dependency Injection statt Service Locator. Trotzdem ein ganz gutes Buch und Service Locator sollte man auch kennen. Dann gibts ein neues Buch "Domain Specific Languages" von ihm, schadet auch nicht, das mal gelesen zu haben, auch wenn es um einbisschen was anderes geht...
    Dann gibts die Reihe "Patterns of Software Architecture", sind glaub 5 Bücher. Die fand ich nicht schlecht, da kannst mal reinschauen.
    Über Design Patterns gibts Bücher wie Sand am Meer mittlerweile. Ich hab nur das Original von den GoF gelesen und fand es gut, glaube nicht, dass die anderen Bücher da großartig was zu der Thematik beitragen.
    Wenn du da mal durch bist, kannst dir was du SOA, DDD, Enterprise Service Bus und ähnlichen Themen anschauen, aber da kann ich jetzt keine konkreten Bücher empfehlen. Gibt eigentlich noch zig Sachen, die man zur Softwarearchitektur dazuzählen könnte, z.B. Complex Event Processing.
    Und natürlich immer Zeitschriften und Artikel lesen, um mitzubekommen, was es da neues gibt. Es gibt grad z.B. eine kleine neue Idee "Event based components" im .NET Bereich, wurde glaub ich von Ralf Westphal angestoßen. Ich sag jetzt gar nichts dazu, was ich davon halte, ich hab nämlich gar keine Meinung dazu, weil ich grad nichts mit .NET zu tun habe. Aber ich denke, es gibt durchaus Fälle wo man sich denken könnte, das passt jetzt gut zu meiner Problematik.



  • Danke für die Bücherliste. Ein paar Titel kommen mir vom Namen her bekannt vor, muss ich irgendwo schon mal drüber gestolpert sein.
    Das Gang of Four hatte mein Informatiklehrer damals mal positiv erwähnt, als wir uns mit ein paar Design Patterns beschäftigt hatten.
    Ich werde mir die Bücher auf jeden Fall nach und nach mal anschauen. Mal schauen, was ich dann später aus meinem neu gewonnenen Wissen "zusammenbastele" 😃


Log in to reply