Zitat von
DelphiManiac:
Wollte dich mal fragen, ob du mir mal eines deiner Projekte schicken könntest?
Ich weiss ist wahrscheinlich zuviel verlangt, aber irgendwie muss man ja dazulernen.
Um was es in dem Projekt geht ist mir eigentlich egal, es geht mir hauptsächlicht um die Kommunikation von Fachkonzept und
GUI.
Vielen Dank ...
Ja, ich verstehe schon was du meinst, dass ist glaube ich auch wirklich eines der Probleme am Programmdesign, man kann es nur mit der Erfahrung verbessern. An sich ist es aber so, dass du nie das perfekte Design von Anfang bis Ende haben wirst, also nicht enttäuscht sein, wenn du an irgendeiner Stelle etwas ändern musst. Die Bücher über die Planung, die Objekt Orientierung, die Entwurfsmuster, ... helfen zwar, aber sie können halt auch nicht mehr leisten als guten Code, den man leicht anpassen kann. Dagegen, dass einige Projekte/Kunden plötzlich doch eine Menge neuer (komplett anderer) Wünsche haben, dagegen kann man nichts tun. Die resultierenden Probleme halten sich damit halt nur stark in Grenzen.
Was ein Projekt angeht, so muss ich dich leider enttäuschen, die wo du ein sauberes Design und eine Halbwegsentkopplung vorfindest sind alles kommerzielle Produkte, an denen hält mein Arbeitgeber bzw. verschiedene Kunden die Copyrights, die darf ich also nicht ohne weitere herausgeben. Ich denke dass verstehst du und wirst das nicht persönlich nehmen. Da ich privat dann immer lieber das leben geniesse als zu programmieren, kann ich dir leider auch hier kein Programm zu schicken.
Ich kann dir nur anbieten dir weiterhin (sogut es geht) bei Entscheidungen eine weitere Meinung zu liefern, wobei ich sagen muss, dass ich genau wie Du und alle anderen auch nur Ideen für's Design habe, es können sich alle gleich irren.
Ich denke das wichtigste für ein gutes Desing ist und bleibt die Einfachheit. Kleine Units, die genau ein Objekt (soweit du OO verwendest) beinhalten (bzw. analog eine bestimmte Funktionalität). Auch dieses Objekt / die Funktionen / Methoden sollten möglichst einfach gehalten sein. Das führt zu wenig Fehlern und verständlichen Code. Möchte man dies konsequent erreichen, führt dass quasi automatisch zur Entkoppelung, da die Darstellung eine andere Funktionalität als die Verwaltung der Daten oder die Logik ist. Design-Pattern helfen hier einfach nur bei dem Verständnis für bestimmte Dinge. Design Entscheidungen sollten immer gut dokumentiert werden, da es sie das Programm ausmachen. Später kann man anhand dieser Entscheidungen leicht nachvollziehen warum das Programm wie aufgebaut ist, was die Wartbarkeit erhöht. Bei den Design-Pattern hat man damit zwei Vorteile:
1. Jmd. hat hier schon ein bestimmtes Problem gelöst
2. Die Lösung ist eindeutig definiert. Verweist man auf ein Pattern ist klar was gemeint ist
Der Rest ist dann noch ein wenig Abstraktion. An sich sollte es bei komplexeren Vorgängen, an denen Verschiedene Objekte beteiligt sind immer einen Controller geben, der zwischen den einzelnen Objekten vermitteln kann. Nur der muss dann alle Objekte kennen, diese sich jedoch nicht. Der Controller kann wiederum mit Abstrakten Klassen oder Interfaces arbeiten, so dass hier die Logik des Controllers unabhängig von der Implementierung der von ihm verwalteten Klassen erhalten bleiben kann. Ja, es ist klar, dass ein Kontroller dann wiederum zwischen Teilsystemen vermitteln kann, wobei der Controller hier nur zwischen anderen Controllern (denen des Teilsystems) vermittelt.
Versucht man diese Prinzipien in eigenen Programmen umzusetzen, so hat man (meiner Erfahrung nach) immer eine recht orgentliche Basis. Wie gesagt, die höchste Priorität hat
imho die Einfachheit.
Gruß Der Unwissende