OOAD-Kenntnisse bzw. -Fähigkeiten verbessern – SELFHTML-Forum Forum als Ergänzung zum SELFHTML-Wiki und zur Dokumentation SELFHTML https://forum.selfhtml.org/self OOAD-Kenntnisse bzw. -Fähigkeiten verbessern Wed, 06 Feb 13 16:01:18 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571329#m1571329 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571329#m1571329 <p>Mahlzeit!</p> <p>Meiner Selbsteinschätzung nach bin ich grundsätzlich ein guter objektorientierter Programmierer, mit der Einschränkung, dass ich im Bereich <a href="http://de.wikipedia.org/wiki/OOAD" rel="nofollow noopener noreferrer">objektorientierte Analyse und Design</a> doch Schwächen habe. Letzteres relativiert natürlich ersteres (eine objektorientierte Software ist leider nicht automatisch gut wartbar, erweiterbar und wiedervendbar).</p> <p>Folglich suche ich Möglichkeiten, die mir helfen, meine OOAD-Fähigkeiten bzw. -Kenntnisse zu verbessern? Ich lese momentan das Buch <a href="http://www.amazon.de/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=sr_1_2?ie=UTF8&qid=1360159064&sr=8-2" rel="nofollow noopener noreferrer">Head First: Object-oriented Analysis und Design</a>. Ich bin noch nicht sehr weit vorgedrungen (Kapitel 4 abgeschlossen), will daher das Buch noch nicht abschließend bewerten. Auch wenn es mir ganz gut gefällt, scheint mir bisher "Erst mal machen, dann besser machen" der dort propagierte Ansatz zu sein. Nun ist es sicherlich so, dass niemand gleich beim 1. Mal ein perfektes Design für seine Software hinkriegt, aber in der Praxis führt dieser Ansatz IMO zu oft zur Situation "Alles wegschmeißen, alles neu machen". Insofern wäre es dann doch nett, wenn man schon am Anfang mit einem einigermaßen vernünftigen Design daherkommen könnte.</p> <p>Falls jemand andere Buchempfehlungen für mich hat, hier vielleicht eine Einschränkungen dazu: Mich interessieren keine<br> * UML-Einführungen, -Referenzen etc.; ich habe UML-Grundkenntnisse und an UML-Diagrammen scheiterts bei mir zumindest nie.<br> * reine Listen von Design Patterns; klar, es schadet nie ein Buch zu lesen, schon gar nicht ein einflussreiches wie das <a href="http://de.wikipedia.org/wiki/Entwurfsmuster_%28Buch%29" rel="nofollow noopener noreferrer">GoF-Buch</a>, aber Pattern-Kataloge gibt es massenhaft Online.</p> <p>Natürlich bin ich nicht auf Bücher beschränkt; wenn wer gute (Online-)Kurse, Übungen o.ä. weiß, dann ist das auch gut.</p> <p>Ein 2. Posting mit einem konkreten Beispiel, über welche Problem ich so stolpere, folgt noch. Wenn mir dazu jemand konkrete Tipps geben kann, würds mich freuen, aber in einem Beitrag wirds zu lang.</p> <p>Grüße<br> Bernhard</p> Konkretes Beispiel Wed, 06 Feb 13 16:09:24 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571330#m1571330 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571330#m1571330 <p>Mahlzeit,</p> <p>um also etwas konkreter zu werden, was so meine Probleme sind, hier ein aktuelles Beispiel aus der realen Welt. Das Beispiel ist mMn wirklich gut, weil die Programmierung grundsätzlich niemandem technische Schwierigkeiten bereiten sollte, aber das ganze sauber, flexibel und erweiterbar hinzukriegen ist dann (zumindest leider für mich) gar nicht mehr so einfach. Die Anforderungen lauten:</p> <p>* Der Benutzer gibt 0 bis n Eingabedateien im CSV-Format (eigentlich ist es kein CSV-Format, aber sehr ähnlich) an (und zu jeder Datei die verwendete Zeichenkodierung).<br> * Der Benutzer gibt eine XML-Ausgabedatei an (Kodierung immer UTF8, die Datei muss einem fix vorgegebenem Schema genügen).<br> * Der Benutzer gibt an, ob die Ausgabedatei überschrieben werden soll oder ob bestehende XML-Elemente aktualisiert (bzw. neue neu eingefügt) werden sollen.</p> <p>* Die Software liest die Eingabedateien, baut aus jeder Zeile in den CSV-Dateien ein XML-Element und fügt dieses in die (neue oder bereits bestehende) Ausgabedatei ein bzw. aktualisiert das entsprechende XML-Element, sofern es bereits in der Ausgabedatei vorhanden ist.<br> * Die Software wird grundsätzlich per Kommandozeile bedient, soll aber auch eine GUI erhalten.<br> * Das Format der CSV-Dateien kann variieren: Z.B. können sich Reihenfolge und Anzahl der Spalten oder das Spaltentrennzeichen ändern. Optimalerweise ist die Software einfach dahingehend anpassbar (durch Implementierung neuer Klassen und Neukompilation), dass sie beliebig strukturierte Textdateien zeilenweise parst und aus den Zeilen XML-Elemente bastelt.<br> * Das Format der Ausgabedatei (d.h., das Schema, dem die XML-Datei entsprechen muss) ändert sich nie.<br> * Weitere Rahmenbedingungen (sind eigentlich, da die Aufgabe technisch einfach ist und es mir nur um das Design geht, hier irrelevant): Programmiersprache ist C#, die GUI wird per <a href="http://en.wikipedia.org/wiki/Windows_Forms" rel="nofollow noopener noreferrer">WinForms</a> erstellt; Windows only.</p> <p>Um sowas sauber zu designen, muss unbedingt das UI von der Programmlogik entkoppelt werden. Mein Ansatz dazu ist bisher ein <a href="http://www.philipphauer.de/study/se/design-pattern/command.php" rel="nofollow noopener noreferrer">Command pattern</a>. Die jeweilige UI ist der Klient, Aufrufer eine Klasse namens "Transformer", mit einer <code class="language-java"><span class="token class-name">Transform</span><span class="token punctuation">(</span><span class="token punctuation">)</span></code>-Methode. Der Klient erzeugt einen Aufrufer und ein Kommando-Objekt (das eine <code class="language-java"><span class="token class-name">Execute</span><span class="token punctuation">(</span><span class="token punctuation">)</span></code>-Methode anbietet), übergibt letzteres dem Transformer und ruft <code class="language-java"><span class="token class-name">Transform</span><span class="token punctuation">(</span><span class="token punctuation">)</span></code> auf. Empfänger gibt es keinen, die Logik ist vollständig im Kommando enthalten. Für jedes Eingabeformat gibt es also ein Kommando, dass das Format kennt und lesen kann. Kommt ein neues Eingabeformat hinzu, so muss ich ein neues Kommando implementieren.</p> <p>Ein Kommando tut folgendes:<br> * Es deserialisiert die Ausgabedatei (falls es diese schon gibt) in eine Objekthierarchie.<br> * Es parst anschließend die Eingabe-Datei(en) und fügt für jede Zeile ein Objekt in die Hierarchie ein bzw. aktualisiert ein bereits bestehendes Objekt.<br> * Es serialisiert die aktualisierte oder völlig neu erstellte Objekthierarchie in die Ausgabedatei.<br> * (Falls sich jemand wundert, warum (de)serialisiert wird: Das ist eine sehr elegante Methode, um <a href="http://stackoverflow.com/questions/1015054/what-is-the-best-way-to-create-an-xml-document-conforming-to-an-xsd-schema" rel="noopener noreferrer">XML-Dokumente gemäß einem Schema zu erstellen</a>.)</p> <p>Das ist jetzt alles ganz schön und gut, nur reicht es halt hinten und vorne nicht. Konkret gibts 2 bzw. 3 Probleme.</p> <p>1. Problem: In den Kommando-Objekten kommt immer irgendwo eine Schleife von ungefähr dieser Form vor:</p> <pre><code class="block language-java"><span class="token keyword">while</span> <span class="token punctuation">(</span><span class="token punctuation">(</span>line <span class="token operator">=</span> <span class="token class-name"><span class="token namespace">stringReader<span class="token punctuation">.</span></span>GetLine</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">)</span> <span class="token operator">!=</span> <span class="token keyword">null</span><span class="token punctuation">)</span> <span class="token punctuation">{</span> string<span class="token punctuation">[</span><span class="token punctuation">]</span> tokens <span class="token operator">=</span> <span class="token class-name"><span class="token namespace">line<span class="token punctuation">.</span></span>Split</span><span class="token punctuation">(</span><span class="token char">';'</span><span class="token punctuation">)</span><span class="token punctuation">;</span> <span class="token comment">// Zeile parsen </span> <span class="token comment">// ... Zeile weiter verarbeiten. </span> <span class="token punctuation">}</span> </code></pre> <p>Für mich ist es naheliegend, die Schleife in eine Methode <code class="language-java"> <span class="token keyword">public</span> <span class="token class-name">List</span><span class="token generics"><span class="token punctuation"><</span><span class="token class-name">MyXmlObject</span><span class="token punctuation">></span></span> <span class="token class-name">GetObjects</span><span class="token punctuation">(</span><span class="token punctuation">)</span></code> einzubetten. Das Problem dabei ist: Natürlich will ich sowohl in der CLI- als auch in der GUI-Variante (in einem Textfeld o.ä.) eine Statusausgabe, die mir sagt, wenn eine Zeile nicht geparst werden konnte. Nachdem das auch mit der GUI funktionieren soll, ist nix mit <code class="language-java"><span class="token class-name">WriteLine</span><span class="token punctuation">(</span><span class="token string">"Fehler in Zeile xyz"</span><span class="token punctuation">)</span><span class="token punctuation">;</span></code> in der Schleife.</p> <p>Eine saubere Lösung dafür fällt mir nicht ein. Wie mache ich das??</p> <p>2. Problem: Wenn irgendwo in den Transformer- oder Kommando-Objekten Exceptions auftreten, müssen die ebenfalls mit beiden GUI-Varianten sauber ausgegeben werden. Ich muss irgendwo einen Layer in meiner Software definieren, der alle Exceptions abfängt und auf eine Weise an den aufrufenden Layer zurückgibt, die für CLI und GUI passt.</p> <p>Auch hier stehe ich an: Wo baue ich die <code class="language-java"><span class="token keyword">catch</span></code>-Klauseln ein und wie gebe ich die Fehlermeldungen an das UI zurück??</p> <p>3. Problem (eigentlich kein Problem, nur ein ungutes Gefühl): Alle Kommando-Objekte sind irgendwie "gleich": Klar, die Execute()-Methode unterscheidet sich möglicherweise sehr stark, aber das UI tut immer</p> <p><code class="language-java"><span class="token class-name"><span class="token namespace">transfomer<span class="token punctuation">.</span></span>Command</span> <span class="token operator">=</span> <span class="token keyword">new</span> <span class="token class-name">MyCommand</span><span class="token punctuation">(</span>string inputFile<span class="token punctuation">,</span> string encoding<span class="token punctuation">,</span> string outputFile<span class="token punctuation">,</span> bool overwrite<span class="token punctuation">)</span><span class="token punctuation">;</span></code></p> <p>oder</p> <p><code class="language-java"><span class="token class-name"><span class="token namespace">transfomer<span class="token punctuation">.</span></span>Command</span> <span class="token operator">=</span> <span class="token keyword">new</span> <span class="token class-name">MyOtherCommand</span><span class="token punctuation">(</span>string inputFile<span class="token punctuation">,</span> string encoding<span class="token punctuation">,</span> string outputFile<span class="token punctuation">,</span> bool overwrite<span class="token punctuation">)</span><span class="token punctuation">;</span></code></p> <p>D.h., die Konstruktorparameter für die Commands sind immer gleich. Ich kann zwar nicht konkret sagen, was damit nicht stimmt, aber irgendwie habe ich kein gutes Gefühl dabei...</p> <p>Soviel also zu konkreten Problemen. Ist kein ganz kurzer Text, also danke an alle, die ihn durchgelesen haben. Vielleicht hat ja jemand Vorschläge, wie man das schön lösen kann.</p> <p>Grüße<br> Bernhard</p> Konkretes Beispiel Wed, 06 Feb 13 16:54:28 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571331#m1571331 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571331#m1571331 <p>Tach!</p> <blockquote> <ol> <li>Problem: In den Kommando-Objekten kommt immer irgendwo eine Schleife von ungefähr dieser Form vor:</li> </ol> <pre><code class="block language-java"></code></pre> </blockquote> <p>while ((line = stringReader.GetLine()) != null) {</p> <blockquote> <p>string[] tokens = line.Split(';'); // Zeile parsen<br>   // ... Zeile weiter verarbeiten.<br> }</p> </blockquote> <pre><code class="block"> > Für mich ist es naheliegend, die Schleife in eine Methode ` public List<MyXmlObject> GetObjects()`{:.language-java} einzubetten. Das Problem dabei ist: Natürlich will ich sowohl in der CLI- als auch in der GUI-Variante (in einem Textfeld o.ä.) eine Statusausgabe, die mir sagt, wenn eine Zeile nicht geparst werden konnte. Nachdem das auch mit der GUI funktionieren soll, ist nix mit `WriteLine("Fehler in Zeile xyz");`{:.language-java} in der Schleife. > Eine saubere Lösung dafür fällt mir nicht ein. Wie mache ich das?? Ohne mich genau au die Gegebenheiten zu erinnern, fällt mir da zumindest Debug als Stichwort ein. Ist es nicht so gewesen, dass man einerseits Debug-Meldungen schreiben kann und andererseits einen Listerner braucht, der darauf reagiert und etwas unternimmt? Andererseits, wenn du einen Rückkanal brauchst, solltest du diesen Rückkanal dem Kommando-Objekt mit übergeben. Da gibt es sicher auch irgendein Pattern mit Namen dafür. Konkret implementiert wäre das ein Delegate oder vielleicht auch ein Event, für das der Aufrufer einen Eventhandler einklinken kann. Den Status als Funktionsergebnis zurückzugeben geht sicher auch. Aber da ist es vielleicht sinnvoller, das eigentliche Ergebnis der Arbeit zurückzuliefern. Dazu später noch was. > 2. Problem: Wenn irgendwo in den Transformer- oder Kommando-Objekten Exceptions auftreten, müssen die ebenfalls mit beiden GUI-Varianten sauber ausgegeben werden. Ich muss irgendwo einen Layer in meiner Software definieren, der alle Exceptions abfängt und auf eine Weise an den aufrufenden Layer zurückgibt, die für CLI und GUI passt. > Auch hier stehe ich an: Wo baue ich die `catch`{:.language-java}-Klauseln ein und wie gebe ich die Fehlermeldungen an das UI zurück?? In den Aufrufer. Nur der weiß im konkreten Fall, was zu tun ist. Ich würde da keine höhere (Gott-)Instanz implementieren, die für sämtliche Problemfälle aller beteiligten Komponenten eine Lösung kennen soll. Gegebenenfalls muss eine Komponente die eigentliche bei ihr auftretende Exception in eine allgemeinere oder auch spezifischere (KommandoException) kapseln. > 3. Problem (eigentlich kein Problem, nur ein ungutes Gefühl): Alle Kommando-Objekte sind irgendwie "gleich": Klar, die Execute()-Methode unterscheidet sich möglicherweise sehr stark, aber das UI tut immer > `transfomer.Command = new MyCommand(string inputFile, string encoding, string outputFile, bool overwrite);`{:.language-java} > oder > `transfomer.Command = new MyOtherCommand(string inputFile, string encoding, string outputFile, bool overwrite);`{:.language-java} > D.h., die Konstruktorparameter für die Commands sind immer gleich. Ich kann zwar nicht konkret sagen, was damit nicht stimmt, aber irgendwie habe ich kein gutes Gefühl dabei... Daran könnte nicht stimmen, dass du statt der Daten den Weg zu den Daten angibst und sich das Kommando die notwendigen Zugriffsprozeduren auch noch mit sich rumschleppen muss, selbst wenn man sie in einer Elternklasse unterbringt. Ich nehme an, "sauberer" ist es, oben Daten einzukippen und unten das Ergebnis abzuholen und Beschaffung und Wegschreiben außerhalb durch Spezialisten erledigen zu lassen. Dann kannst du diese Spezialisten bei Bedarf anpassen oder neue erstellen, ohne die bestehende Funktionalität in den Transform-Klassen zu beeinträchtigen. Zur Not übergibst du halt die fertig initialisierten Spezialisten als Parameter. So bekommst dein Transformationskommando weniger Dinge zu tun, die eigentlich gar nicht zu seinen direkten Aufgaben zählen. Vor allem auch im Hinblick auf Testbarkeit ist es auf diese Weise besser, weil da nicht irgendwelche Festplattenzugriffe mit getestet werden, sondern Dummys übergeben werden können. dedlfix. </code></pre> Konkretes Beispiel Wed, 06 Feb 13 17:46:41 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571332#m1571332 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571332#m1571332 <p>Hi!</p> <blockquote> <blockquote> <ol> <li>Problem<br> Ohne mich genau au die Gegebenheiten zu erinnern, fällt mir da zumindest Debug als Stichwort ein. Ist es nicht so gewesen, dass man einerseits Debug-Meldungen schreiben kann und andererseits einen Listerner braucht, der darauf reagiert und etwas unternimmt?</li> </ol> </blockquote> </blockquote> <blockquote> <p>Andererseits, wenn du einen Rückkanal brauchst, solltest du diesen Rückkanal dem Kommando-Objekt mit übergeben. Da gibt es sicher auch irgendein Pattern mit Namen dafür. Konkret implementiert wäre das ein Delegate oder vielleicht auch ein Event, für das der Aufrufer einen Eventhandler einklinken kann.</p> </blockquote> <p>Jaaa, sehr gut, das sind schon mal 2 Ansätze, die mich weiterbringen. Die 2. Lösung mit Event bzw. Delegate ist mir soweit klar. Die 1. Lösung noch nicht 100%ig; vor allem ist mir nicht unbedingt klar, wo der Unterschied zu Lösung 2 wäre. In meinen Augen läuft das doch wieder auf eine eventbasierte Lösung hinaus, oder?</p> <blockquote> <p>Den Status als Funktionsergebnis zurückzugeben geht sicher auch. Aber da ist es vielleicht sinnvoller, das eigentliche Ergebnis der Arbeit zurückzuliefern. Dazu später noch was.</p> </blockquote> <p>Das Problem hierbei ist, dass die Statusausgaben Bezug auf Zeilen nehmen, ein Kommando aber eine ganze Datei verarbeitet. Der Rückgabewert wäre dann ein möglicherweise aus sehr vielen Zeilen der Form "Zeile i konnte nicht geparst werden, weil ... Zeile i+j konnte nicht geparst werden, weil ..." bestehender String. Das erscheint mir unsauber.</p> <blockquote> <blockquote> <ol start="2"> <li>Problem<br> In den Aufrufer. Nur der weiß im konkreten Fall, was zu tun ist. Ich würde da keine höhere (Gott-)Instanz implementieren, die für sämtliche Problemfälle aller beteiligten Komponenten eine Lösung kennen soll. Gegebenenfalls muss eine Komponente die eigentliche bei ihr auftretende Exception in eine allgemeinere oder auch spezifischere (KommandoException) kapseln.</li> </ol> </blockquote> </blockquote> <p>Ich bin mir nicht sicher, ob wir uns hier verstehen. Meinst du, ich soll sämtliche <code class="language-java"><span class="token keyword">catch</span></code>-Klauseln in der UI unterbringen? Das wäre natürlich insofern praktisch als ich in den Kommandos und im Transformer Exceptions einfach ignorieren kann. Aber irgendwie muss ich dann in beiden UIs jeweils zig verschiedene Exceptions abfangen.</p> <p>Zu den Reaktionen auf Exceptions ist auch noch zu sagen: Ich wollte ja auch keinen Layer definieren, der für alle Exceptions eine "Lösung" anbietet. Die ist na noch nichtmal unbedingt notwendig. Auf der Kommandozeile würde ich z.B. einfach eine Fehlermeldung rausschreiben, wenn eine Eingabedatei nicht gefunden wurde und das auslösende Kommando ignorieren. Ich wollte einen Layer, der alle Exceptions abfängt und auf einheitliche Art und Weise an die UI weiterreicht; echte Fehlerbehandlung hätte ich da nicht vorgesehen. Insofern ist eine KommandoException o.ä. sicherlich nicht verkehrt; sowas in die Richtung hab ich auch schon implementiert.</p> <p>Was dieses Problem angeht, bin ich noch nicht wirklich schlauer.</p> <blockquote> <blockquote> <ol start="3"> <li>Problem<br> Daran könnte nicht stimmen, dass du statt der Daten den Weg zu den Daten angibst und sich das Kommando die notwendigen Zugriffsprozeduren auch noch mit sich rumschleppen muss</li> </ol> </blockquote> </blockquote> <p>Ich glaube, das fasst meine Bedenken ziemlich gut in Worte.</p> <blockquote> <p>Ich nehme an, "sauberer" ist es, oben Daten einzukippen und unten das Ergebnis abzuholen und Beschaffung und Wegschreiben außerhalb durch Spezialisten erledigen zu lassen. Dann kannst du diese Spezialisten bei Bedarf anpassen oder neue erstellen, ohne die bestehende Funktionalität in den Transform-Klassen zu beeinträchtigen. Zur Not übergibst du halt die fertig initialisierten Spezialisten als Parameter. So bekommst dein Transformationskommando weniger Dinge zu tun, die eigentlich gar nicht zu seinen direkten Aufgaben zählen.</p> </blockquote> <p>Zwar habe ich noch keine konkrete Vorstellung, wie die Implementierung letztlich aussehen soll, aber das gibt mir schon mal die richtige Richtung vor.</p> <blockquote> <p>Vor allem auch im Hinblick auf Testbarkeit ist es auf diese Weise besser, weil da nicht irgendwelche Festplattenzugriffe mit getestet werden, sondern Dummys übergeben werden können.</p> </blockquote> <p>Testbarkeit, richtig, das habe ich ganz vergessen. Man will ja auch für Kommandos, Transformer etc. Unit-Tests schreiben; das macht lose Kooplung nochmal doppelt so wichtig.</p> <p>Danke<br> Bernhard</p> Konkretes Beispiel Wed, 06 Feb 13 18:52:19 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571333#m1571333 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571333#m1571333 <p>Tach!</p> <blockquote> <p>Die 2. Lösung mit Event bzw. Delegate ist mir soweit klar. Die 1. Lösung noch nicht 100%ig; vor allem ist mir nicht unbedingt klar, wo der Unterschied zu Lösung 2 wäre. In meinen Augen läuft das doch wieder auf eine eventbasierte Lösung hinaus, oder?</p> </blockquote> <p>Im Prinzip ja. Und es war nicht Debug sondern Trace. Aber Trace ist ja auch nicht zur Fortschrittsanzeige gedacht, sondern wäre dann missbräuchlich verwendet.</p> <blockquote> <p>Das Problem hierbei ist, dass die Statusausgaben Bezug auf Zeilen nehmen, ein Kommando aber eine ganze Datei verarbeitet. Der Rückgabewert wäre dann ein möglicherweise aus sehr vielen Zeilen der Form "Zeile i konnte nicht geparst werden, weil ... Zeile i+j konnte nicht geparst werden, weil ..." bestehender String. Das erscheint mir unsauber.</p> </blockquote> <p>Es gibt auch List<string> oder List<ParseError>.</p> <blockquote> <blockquote> <blockquote> <ol start="2"> <li>Problem<br> In den Aufrufer. Nur der weiß im konkreten Fall, was zu tun ist. Ich würde da keine höhere (Gott-)Instanz implementieren, die für sämtliche Problemfälle aller beteiligten Komponenten eine Lösung kennen soll. Gegebenenfalls muss eine Komponente die eigentliche bei ihr auftretende Exception in eine allgemeinere oder auch spezifischere (KommandoException) kapseln.<br> Ich bin mir nicht sicher, ob wir uns hier verstehen. Meinst du, ich soll sämtliche <code class="language-java"><span class="token keyword">catch</span></code>-Klauseln in der UI unterbringen? Das wäre natürlich insofern praktisch als ich in den Kommandos und im Transformer Exceptions einfach ignorieren kann. Aber irgendwie muss ich dann in beiden UIs jeweils zig verschiedene Exceptions abfangen.</li> </ol> </blockquote> </blockquote> </blockquote> <p>Deswegen ja die Verallgemeinerung zu einer einzigen Exception-Klasse mit der eigentlichen im Huckepack. Allerdings nicht Exception sondern eben KommandoException o.ä.</p> <blockquote> <p>Testbarkeit, richtig, das habe ich ganz vergessen. Man will ja auch für Kommandos, Transformer etc. Unit-Tests schreiben; das macht lose Kooplung nochmal doppelt so wichtig.</p> </blockquote> <p>Man nennt das dann Dependency Injection. Zudem, such mal die Videos zu "<a href="http://www.g-truc.net/post-0182.html" rel="nofollow noopener noreferrer">google clean code talks</a>", besonders das Don't look for Things (und die anderen auch).</p> <p>dedlfix.</p> Konkretes Beispiel Wed, 06 Feb 13 19:53:40 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571335#m1571335 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571335#m1571335 <p>Hi!</p> <blockquote> <p>Im Prinzip ja. Und es war nicht Debug sondern Trace. Aber Trace ist ja auch nicht zur Fortschrittsanzeige gedacht, sondern wäre dann missbräuchlich verwendet.</p> </blockquote> <p>Hmm, ok. Hast du vielleicht einen Link, wo diese Debug/Trace-Geschichte etwas detaillierter erläutert wird?</p> <blockquote> <p>Zudem, such mal die Videos zu "<a href="http://www.g-truc.net/post-0182.html" rel="nofollow noopener noreferrer">google clean code talks</a>", besonders das Don't look for Things (und die anderen auch).</p> </blockquote> <p>Mach ich.</p> <p>Danke<br> Bernhard</p> Konkretes Beispiel Mon, 18 Feb 13 12:21:51 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571334#m1571334 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571334#m1571334 <p>Mahlzeit!</p> <blockquote> <p>Zudem, such mal die Videos zu "<a href="http://www.g-truc.net/post-0182.html" rel="nofollow noopener noreferrer">google clean code talks</a>", besonders das Don't look for Things (und die anderen auch).</p> </blockquote> <p>Eins muss ich sagen: Ich hab mir die 4 Vorträge inzwischen (teilweise mehrfach) angesehen und die sind wirklich _verdammt_ gut. Sollte sich jeder, der das liest auch ansehen.</p> <p>Grüße<br> Bernhard</p> Konkretes Beispiel Wed, 06 Feb 13 20:08:09 Z https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571336#m1571336 https://forum.selfhtml.org/self/2013/feb/6/ooad-kenntnisse-bzw-faehigkeiten-verbessern/1571336#m1571336 <p>Tach!</p> <blockquote> <p>Hmm, ok. Hast du vielleicht einen Link, wo diese Debug/Trace-Geschichte etwas detaillierter erläutert wird?</p> </blockquote> <p>Debug ist anders, einfacher. Das schreibt mehr oder weniger nur in die Konsole. Trace ist ausgefeilter, das schreibt ohne weiteres erstmal gar nichts. Da braucht es TraceListeners, um die Meldungen aufzufangen. Ich kenne dazu auch keine Literatur, aber für Microsoft-Software ist das MSDN die erste Anlaufstelle. Nicht nur, dass es in den Klassendokumentationen üblicherweise recht brauchbar beschrieben wird, es existieren mitunter auch tutorialäquvalente Anleitungen.</p> <p>dedlfix.</p>