Zitat von
Chemiker:
Ich habe ja schon einige Gehversuche in
OOP unternommen, aber meistens endet es damit, dass ich eine riesige sehr unübersichtliche Mammut-Class bekomme.
An sich ist die Lösung eigentlich ganz einfach, alles was groß ist kann auch zerlegt werden. Wie würdest Du das in der strukturierten Programmierung angehen? Ich meine hast Du eine große, einzelne Funktion, zerlegst Du die einfach in viele kleinere Funktionen (was eine Menge Vorteile bietet).
Hast Du nun eine Mega-
Unit, die zig Funktionen enthält, dann zerlegst Du das ganze in mehrere Units. Klassen sind ebenso nur eine weitere Strukturierungeinheit. Besonderheit dabei, Du hast halt Exemplare. Das alles kannst Du nachbilden in der strukturierten Programmierung. So kannst Du Zellen einfach als Record anlegen und hier unterschiedliche Exemplare durch eindeutige IDs unterscheiden. Eine Klasse bringt diese eindeutige Unterscheidung einfach schon mit, jedes Exemplar enthält seinen Zustand (seine eigene Belegung der Variablen). Bei gleichem Zustand ist dann halt auch das Verhalten gleich.
Zitat von
Chemiker:
Die meisten Schwierigkeiten bereiten mir die Schnittstellen von einer Klasse zu anderen.
Ich will das mal an einem Beispiel verdeutlichen:
Ich konstruiere eine OLEBasisClass die in der Lage ist verschiede
OLE-Applikationen zu starten. Das ist sozusagen das Grundgerüst was alle unter const aufgeführten Applicationen gemeinsam haben.
Soweit ist das doch schon ein guter Ansatz. Alles was gleich gemacht wird ist dann schon mal in einer Basisklasse. Wie Hansa schon sagte, kurz dahinter dürften die Gemeinsamkeiten auch schon enden.
Zitat von
Chemiker:
Mir ist immer noch nicht klar, wie diese sagen wir mal Unterklassen von Excel entwickelt werden sollen und diese dann in THPLExcel-Class aufgerufen werden sollen.
Oder, ist der ganze Ansatz falsch und man fängt zuerst mit der Zelle an weiter zum WorkSheet usw. und arbeitet sich weiter bis zur Excel-Application vor?
Leider verstehe ich hier die zugrunde liegende Frage noch nicht vollständig. An sich ist es egal ob Du jetzt top down (von groß nach klein) oder bottom up rangehst. Du kannst bei den Zellen anfangen und von dort aufwärst arbeiten, Du kannst aber auch so vorgehen wie Du es schon getan hast.
Wie bereits gesagt, es gibt kein Patenrezept. Der beste Weg ist immer, dass Du erst ein Modell erstellst, welches vollständig ist. Das heißt, dass Du Dir wirklich aufschreibst (z.B. in einem Diagramm) wie Deine Zerlegung in Teilprobleme / Klassen aussieht und welche Schnittstellen die Klassen bieten. Daran kannst Du dann leicht überprüfen ob die Modellierung vollständig ist (Du alle Probleme lösen kannst).
Das Modell kann dabei sehr abstrakt vorliegen, was es für Dich einfacher macht, die konkrete Implementierung ist halt egal (was durch das OO vereinfacht wird). Änderungen am Modell sind verhältnismässig einfach möglich und kosten eben wenig Zeit.
Vollständiges Planen ist dabei übrigens unabhängig vom gewählten Paradigma von Vorteil! Hast Du jetzt ein solches Modell, so ist die Umsetzung entsprechend einfach.
Ein anderes Problem ist dann weiterhin die Modellierung. Die kann immer nur zu einem bestimmten Problem passen. Ändern sich die Anforderungen, so kann es sein, dass sich eine andere Modellierung als geeigneter erweist. Im besten Fall wirst Du nur erweitern müssen, in der Regel kommt es aber an einzelnen Stellen auch zu Änderungen.
Die typische Frage die sich stellt heißt immer, was alles in eine eigene Klasse gehört. Die beiden Extreme sind dabei die Verwendung von nur einer Klasse oder eben je einer Klasse pro Variable oder Methode. Beides führt natürlich nicht weit. Besser ist es die berühmte Mitte zwischen diesen Extremen zu finden. Das ist dabei einerseits reine Erfahrungssache und kann sich andererseits halt auch ändern.
Sagen wir mal Du verwendest eine Worksheet - Klasse, welche einfach pro Zelle nur einen String speichert. Da erscheint es fragwürdig eine solche Zelle eine eigene Klasse zu verwenden. Ist die Implementierung fertig ist das schon mal super. Jetzt merkst Du aber, dass Du gerne Formatierungseigenschaften mit aufnehmen würdest, dazu gehört eine Schriftart, die Größe, die Farbe, Hintergrund, ... Wie Du unschwer merkst, der Umfang der Informationen die pro Zelle gespeichert werden ist deutlich größer als der enthaltene String. Entsprechend lohnt sich nun eine eigene Klasse. Natürlich kann man dies in dem einfachen Fall ggf. schon abschätzen, aber nicht immer ist das möglich. Kommt es zu so einer Situation, dann ist das kein riesen Problem. Was man tut ist einfach auslagern. Man erstellt eine neue Klasse TZelle, welche entsprechend diese Informationen zusmamenfasst und verwendet diese innerhalb des Worksheet.
Wie gesagt, es gibt keine Vorschrift wie man alles richtig macht. Die meisten Probleme - denke ich - lassen sich durch eine ausreichende Planung umgehen. An sich solltest Du einfach erstmal versuchen die Gesamtproblematik (Excel File bearbeiten) in Teilprobleme zerlegen. So wie Du es eben intuitiv machen würdest. Die Teilprobleme kannst Du erstmal je als eine Klasse betrachten. Wenn Du einfach Dinge wie Datei, Worksheets und Zellen trennen kannst (Dir sind ja die Unterschiede bekannt), dann kannst Du die eben auch als Klasse betrachten bzw. modellieren. Die zugehörigen Eigenschaften sind eben so einfach zu erkennen. Um bei der Zelle zu bleiben, sie hat eine Position (Spalte und Zeile), eine Formatierung, einen Inhalt, ... Das alles sind die Eigenschaften die Du ins Modell aufnimmst, fertig. Natürlich kannst Du auch gleich Methoden modellieren, die z.B. eine validierung der Werte vornehmen (z.B. keine Zeile > 65535). Hast Du das Modell fertig (ohne vollständig zu überlegen wie Du das alles implementierst), dann kannst Du daran überprüfen, ob alles Anwendungsszenarien möglich sind. Ist dies nicht der Fall, solltest Du am Modell eben erkennen was fehlt und nachbessern können. Irgendwann ist dann das Modell rund und Du kannst Dein Code - Skelett daraus erstellen. Die Schnittstellen der Klassen stecken direkt im Modell und können entsprechend übernommen werden. Durch die Möglichkeit der Abstraktion und damit verbunden der Austauschbarkeit der Implementierungen kannst Du dann eben einfach mit Dummy - Implementierungen die Umsetzung (sowohl top down, als auch bottom up) beginnen und sukkzessive vervollständigen.