Fehlerbehandlung in mehrschichtigen Systemen

… oder kurz: Schichten und Exceptions

Die Delphi-Tage 2012 sind zu Ende. Wie üblich hab ich nen Vortrag gehalten. Diesmal gings um Schichten, um Exceptions und was das eine mit dem anderen zu tun hat.

Abstract:
Wie strukturiert man eigentlich Software? Braucht Software überhaupt eine Struktur? Und, wenn ja, wie kann die aussehen? Und wie behandelt man eigentlich Fehler und Ausnahmesituationen? Sind Exceptions hier das Maß aller Dinge? Wie setzt man sie richtig ein? Und was hat das Ganze mit Schichten zu tun? Dieser Vortrag gliedert sich in zwei Teile. Im ersten Teil wird gezeigt, wie man Software in Schichten strukturieren kann und welche Vorteile das hat. Außerdem werden ein paar Buzzwords wie “Architektur”, “Layers” und “n-Tier” geklärt. Der zweite Teil befasst sich mit Exceptions, wie man diese richtig einsetzt und was das Ganze mit Schichten zu tun hat.

Resümee:
Ich halte gerne Vorträge und noch lieber halte ich sie, wenn interessiertes Publikum vorhanden ist. Und das war es. Und es hat Spaß gemacht. Der Raum war voll und das obwohl die parallel stattfindenden Vorträge sich eigentlich auch sehr interessant angehört haben. Was mich besonders gefreut hat, war, dass es viele gute Fragen gab. Es ist immer schön zu sehen, wenn man mit dem Thema etwas getroffen hat, das nicht nur einen selbst interessiert.

Von meiner Seite aus muss ich sagen, dass eigentlich alles ziemlich gut geklappt hat. An Details kann man natürlich immer feilen. Deshalb mal wieder die Bitte um Feedback. Diverse positive Rückmeldungen hab ich schon bekommen (was mich sehr gefreut hat). Da ich mich aber nur verbessern kann, wenn ich weiß, was nicht so gut war, bitte ich auch und insbesondere um negatives Feedback. Was war nicht den Erwartungen entsprechend, was war verbesserungswürdig, unnötig oder unverständlich? Was hat gefehlt?

Folien und Vortragsnotizen:
Ich habe diesmal getrennte Folien und Vortragsnotizen. Auf den Folien steht nicht sonderlich viel drauf, was sie für den Vortrag passender gemacht hat (denke ich zumindest). Dafür gibts zusätzliche Vortragsnotizen. Diese sind demgegenüber ausführlicher und enthalten teilweise sogar ganze Textabsätze. Das ist jetzt nicht so detailliert und ausgefeilt wie ein Tutorial, aber es sollte ausreichen, um auch verständlich zu sein, ohne dass man den Vortrag gehört hat. Feedback hierzu ist natürlich auch willkommen. Also hier die Downloads:
Download: Schichten und Exceptions: Folien (Größe: 2.99 MB; bisher 149 mal heruntergeladen)
Download: Schichten und Exceptions: Vortragsnotizen (Größe: 3.05 MB; bisher 168 mal heruntergeladen)

Hinweise:

• Danke für den Hinweis, dass in den Folien ein “Create” gefehlt hat. Ist jetzt korrigiert.
• Nach dem Vortrag würde ich noch auf EurekaLog als Alternative zu madExcept hingewiesen. Der Hinweis findet sich nun auch in den Vortragsnotizen.
• Ebenfalls vielen Dank für den Hinweis, dass man die UML-Packages, die erstmal ja nur eine logische Gruppierung darstellen, mit Delphi-Packages umsetzen kann. Der eigentlich passende Mechanismus wären IMHO wohl Namespaces, die es in Delphi in der Form nicht gibt. Und wenn man sich .NET und Java ansieht, wird man feststellen, dass es dort beides gibt: Namespaces/Java-Packages und Assemblies/jar-Dateien. Beides, logische und physische Gruppierung, ist orthogonal, d.h. vollkommen unabhängig voneinander. So kann eine Assembly mehrere Namespaces enthalten und umgekehrt. Dabei ist die physische Gruppierung die eindeutig schwergewichtigere. Trotzdem halte ich das für einen wertvollen Hinweis. Man sollte sich durchaus überlegen, ob Delphi-Packages nicht doch in Frage kommen, um einzelne Schichten/Packages voneinander zu entkoppeln. Ist wohl eindeutig eine Überlegung wert.
• Die Graphik mit dem schlecht wartbaren Subsystem wurde mit einer Software des Fraunhofer IESE erstellt. Links dazu sind in den Vortragsnotizen.
• Zwei “Problembereiche” von Exceptions wurden noch angesprochen: DLLs und Threads. Ich hab nochmal nachgeguckt, aber leider hab ich keine Links dazu parat. Und ein Patentrezept hab ich leider auch nicht. Von daher kann ich wohl nur wiederholen, was ich schon als Antwort gegeben hatte: Exceptions an DLL- und Threadgrenzen vermeiden (noch mehr als sonst) und ggf. auf die anderen Fehlerbehandlungsmechanismen ausweichen (Fehlercodes, OnError-Events, etc.). Man könnte sich auch andere Ausweichstrategien überlegen. Beispielsweise Records mit den Fehlermeldungen zurückgeben, Window-Messages verschicken, etc. Auch kann man sich um ne DLL auf der Aufruferseite wieder einen Wrapper schreiben, der Fehlercodes, die als Ausweichstrategie verwendet wurden, wieder in Exceptions umschreibt. Leider gibt es wohl keine perfekte Lösung. Was im konkreten Fall nun vorzuziehen ist, hängt dabei wohl auch stark von den jeweiligen Rahmenbedingungen und Anforderungen ab.
• Testgetriebene Entwicklung/Test-First-Ansätze wurden erwähnt. Genau genommen unterscheide ich zwischen den beiden Begriffen (was nicht alle tun). Vielleicht mach ich dazu mal nen separaten Blog-Post darüber. Vereinfacht gesagt geht es darum, den Test-Code zuerst zu schreiben. Und das hat dann Auswirkungen auf das Design. Eigentlich geht es noch um viel mehr. Weil ich das aber hier nicht alles erwähnen kann, verweise ich lieber auf Wikipedia, die einschlägigen Blogs und diverse Bücher zum Thema.
• Zu Assertions hab ich letztes Jahr schon ein bisschen was gesagt. Außerdem kann ich auf das auch anderweitig unbedingt zu empfehlende Buch “The Pragmatic Programmer” verweisen. Da gibts auch ein kleines bisschen etwas dazu. Im übrigen sind Andrew Hunt und David Thomas auch meiner Meinung, dass man Assertions nicht unbedingt deaktivieren muss.
• Design by Contract wurde auch kurz erwähnt. Hier ein passender Link dazu.
• Ich hoffe, ich hab hier nichts vergessen. Vielen Dank jedenfalls auch für die anderen Kommentare.

Nachtrag:
Eine Möglichkeit zur Verbesserung ist mir gerade selbst noch eingefallen: Mit einem Laserpointer würde sich wohl deutlich besser auf die Leinwand zeigen können als mit der Hand. Ich glaub, ich sollte mir für nächstes Jahr so ein Ding zulegen. Ansonsten würde ich gerne wissen, ob ich verständlich war. Sowohl inhaltlich alsauch sprachlich. War ich zu schnell, zu langsam, zu laut, zu leise? Wie war meine Körperhaltung und keine Ahnung was… Ich bitte auch um Kritik an Kleinkram.

Enbugging — Wie wir Fehler machen und wie wir sie vermeiden

Wie im letzten Jahr, hab ich auch dieses Mal wieder einen Vortrag auf den Delphi-Tagen gehalten. Diesmal gings ums Fehler vermeiden. Man könnte auch sagen, um konstruktive QA-Maßnahmen. Egal. Jedenfalls gings um Bugs.

Abstract

“Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.” So liest man zuweilen im Netz und manchmal ist es nur zu wahr. Stunden verbringen wir damit, umständlich einen Fehler zu suchen, den wir zuvor noch ganz mühelos einbauen konnten. Wäre es da nicht praktischer, statt uns mit Debugging aufzuhalten, das Enbugging, das Einfügen von Fehlern gar nicht erst zu betreiben? Letztendlich sind wir ja eigentlich selbst schuld: Bugs entstehen nicht aus dem Nichts. Vielmehr erzeugen wir — meist unabsichtlich — Bedingungen, unter denen diese kleinen Krabbelviecher so prächtig gedeihen. Dieser Vortrag soll zeigen, wie Bugs entstehen und was wir dagegen tun können. Eine vollständige Betrachtung des Themas kann dabei natürlich nicht erfolgen. Stattdessen wird ein Überblick gegeben, um danach einzelne Aspekte zu vertiefen.

Folien

Wie versprochen gibts hier die Vortragsfolien: Download: Enbugging (Größe: 1.14 MB; bisher 355 mal heruntergeladen)

Ich hab wieder eine Gratwanderung zwischen vortragsunterstützenden Folien und Infos für alle, die den Vortrag nicht gesehen haben, versucht. Ob mir das gelungen ist, darf jeder selbst beurteilen (und mir am besten auch noch ein bisschen Feedback geben).

Hinweise

• Eigentlich wollte ich noch erwähnen, dass Tony Hoare (der übrigens auch den QuickSort erfunden hat) auch dran schuld ist, dass in Pascal die geschweiften Klammern Kommentare sind. Hoare hat Vorbedingungen und Nachbedingungen in geschweiften Klammern vor bzw. hinter Code geschrieben (“Hoare-Tripel“) und damit formale Verifikation gemacht. Niklaus Wirth gefiel das Ganze so gut, dass er die geschweiften Klammern zu Kommentarzeichen machte.
• Um die Beispiele zu verstehen, sollte man sich genau angucken, wie die Bezeichner (insbesondere die Klassen) heißen. Man sollte daraus erraten können, worum es geht. Meine Beispiele waren meist allgemein bekannte Datenstrukturen (List, Map, Set) oder standen in losem Zusammenhang mit Feedreadern, HTML-Parsern u.ä.
• “Meine Fehlerliste” enthält viel zu wenige Daten, um hieraus schon etwas Sinnvolles ableiten zu können. Da muss ich noch mehr sammeln. Das hab ich beim Vortrag zwar schon dazu gesagt, aber es steht so explizit nicht in den Folien.
• Was ich auch im Vortrag erwähnt hab, aber nicht auf den Folien steht: Bidirektionale Assoziationen sind starke Kopplungen. Also wenn sich zwei Module gegenseitig kennen, anstatt dass nur ein Modul das andere kennt, aber nicht umgekehrt. Man sollte deshalb zusehen, dass man möglichst nur einseitige Beziehungen hat.
• Der Anhang enthält noch weitere Beispiele und Hinweise auf weiterführende Themen, die nicht angesprochen werden konnten.

Errata

• Auf Folie 60 fehlt ein not. Es müsste also heißen if not FInnerList.Contains(item) then.

Bitte um Feedback

Das Feedback, das ich bisher bekommen hab, war durchweg positiv. Das freut mich. Ich will hier aber trotzdem nochmal nach Feedback und explizit auch Kritik fragen. Nur, wenn ich weiß, was ich besser machen kann, kann ich in Zukunft etwas weniger schlimme Vorträge machen… *g*

Insbesondere würde mich folgendes interessieren:

• Hab ich verständlich geredet? War ich vielleicht zu schnell?
• Waren die Beispiele verständlich? Nachvollziehbar? Praxistauglich?
• Wie versteht man die Folien, wenn man sich den Vortrag nicht angehört hat?
• Waren Thema und Inhalt angemessen? Zu theoretisch? Zu einfach? Zu schwer? Zu trivial?
• Kann ich sonst etwas verbessern?

Enbugging — Was ich auf den Delphi-Tagen erzählen will

“Wenn Debugging der Vorgang ist, Fehler aus einem Programm zu entfernen, dann ist Programmierung der Vorgang, Fehler in ein Programm einzubauen.” Und ich fürchte das stimmt. Debugging ist manchmal nervig, auf jeden Fall aber zeitaufwändig. Und dabei sind wir doch eigentlich selbst schuld: Mühelos bauen wir Fehler in unseren Code ein, damit wir diese dann wieder mit viel Mühe erkennen, lokalisieren und beheben können.

Schön wäre es doch, wenn wir die Fehler gar nicht erst einbauen würden. Wir tun das nicht bewusst. Man könnte das jetzt einfach als Nachlässigkeit oder “Versehen” abtun, aber meistens ist es mehr: Wir erzeugen Bedingungen unter denen Bugs leicht entstehen. Wir tricksen und quasi selbst aus, indem wir unsere Programme so entwerfen, dass wir fast unausweichlich Bugs machen müssen, wenn wir nicht höllisch aufpassen. Uns ist das nicht immer bewusst, aber es ist so. Einige solche Bugschleudern hab ich selbst schon fabriziert.

Um dem zu begegnen gibt es IMHO drei Dinge, die wir tun können:

1. Verstehen wie Code funktioniert, welche Probleme und Fallstricke existieren und welche Fehler man machen kann.
2. Verstehen welche Fehler man persönlich macht.
3. Bedingungen erzeugen, unter denen Bugs nicht so leicht entstehen oder zumindest schneller erkannt werden.

Das ist mehr oder weniger das, was ich auf den diesjährigen Delphi-Tagen in Köln erzählen will. Einen Vorgeschmack gibts schonmal hier: Download: Enbugging-preview (Größe: 383.76 kB; bisher 155 mal heruntergeladen)

Ich hab viel zu erzählen und weiß noch nicht ganz, ob ich davon noch etwas kürzen oder verändern muss. Deshalb erstmal nur das Kapitel zur Einführung. Den Rest gibts dann als finale Version nach oder kurz vor den Delphi-Tagen. Das, was ich hier zeige, ist zwar mit Abstand das langweiligste Kapitel, aber zumindest ist ein Inhaltsverzeichnis dabei, sodass man schonmal nen Eindruck gewinnen sollte, ob es sich lohnt, mir zu zu hören.

Alles in Allem werde ich nichts bahnbrechend Neues vorstellen. Das ist teilweise Erstsemester-Stoff [1], aber ich werde versuchen, aufzuzeigen, warum das wirklich praxisrelevant ist. Relevanter als ich das im ersten Semester erkannt hab. Es wird ne Menge Beispiele geben, die auch mit Abstand die meiste Arbeit gemacht haben und hoffentlich den ein oder anderen Aha-Effekt erzeugen. Mal sehen, ob mir das gelingt. Zumindest ist das mein Ziel.

Vorab kann ich schonmal sagen, dass ich den Titel geklaut hab. Und zwar von diesem sehr lesenswerten Artikel: The Art of Enbugging von Andy Hunt und Dave Thomas.

[1] OK, wirklich nur teilweise

Gefangen, nicht gefunden! #18

Informatik und Anderes

• Böser Bug. Böser Bug. *Sehr* böser Bug! Aber sehr lehrreich. Einmal, weil man hier deutlich sieht, wie wichtig das Testen ist und wie schnell man einen fatalen Fehler übersieht. Und zum zweiten zeigt das Beispiel recht schön, warum Haftungsfragen auch bei eigentlich nicht sicherheitskritischer Software eine Rolle spielen können. Ich bin ganz froh darüber, dass ich gerade eine passende Vorlesung zu dem Thema höre. Die Rechtsprechung ist hier teilweise *sehr* merkwürdig, was Software anbelangt. (via).
• “The great thing about TCP jokes is that you always get them.” Zugegeben: Es hat ein bisschen gedauert, bis ich den verstanden hab (Das Problem bei TCP-Witzen ist ja auch, dass es ziemlich lang dauern kann, bis man anfängt, sie zu verstehen. ). Aber ich find den richtig gut. Und es gibt noch mehr von der Sorte. Die sind wohl irgendwie in Twitter entstanden. Noch ein paar gute:
  • @eigenrick: The problem with TCP jokes is that people keep retelling them slower until you get them. #protolol
  • @reconbot: WHO HAS ANY ARP JOKES? #protolol
  • @OhMeadhbh: the SYN flood attack #protolol: “knock knock. who’s there? knock knock. who’s there? knock knock. who’s there? …”
  • @yoz: order best is tell that The you thing can about jokes BitTorrent them in any. #protolol
  • @peter_tonoli: Chuck Norris has only one OSI level – Physical

  (via)

• Per Zufall bin ich auf eine sehr interessante Seite gestoßen: ioexception.de. Das ist ein Blog von ein paar Informatik-Studenten der Uni Ulm. Und da gibts so einige interessante Inhalte zu entdecken:
• Zustandsautomaten, State Pattern und Java Enums. Hinlänglich bekannt, aber nochmal schön zusammengefasst. Außerdem vielleicht ganz interessant für meine SEP-Studenten, die gerade einen Bot für ein Netzwerkkartenspiel schreiben dürfen. Und hier bietet sich eben das StatePattern und die genannte Umsetzung an. Das ist nicht die einzige Möglichkeit, Automaten in Code zu gießen. Bei Gelegenheit schreib ich da mal was dazu…
• Eine interessante Idee: git als Update-Mechanismus verwenden.
• Auch die anderen Posts lohnen sich. Einfach mal reingucken…
• Martin Fowler hat einen sehr interessanten Artikel über Flags in Methoden. Dem kann ich eigentlich kaum noch etwas hinzufügen. Außer vielleicht, dass Methoden-Flags i.d.R. Kontrollkopplungen sind, also den Kontrollfluss der Methode beeinflussen, statt ein Datum darzustellen. Und Kontrollkopplungen sind starke Kopplungen, d.h. man sollte sie vermeiden.
• Mein Vortrag auf den Delphi-Tagen ist wohl gesetzt. Zumindest verschickt Embarcadero schon Rundmails, in denen ich als Speaker genannt werde. Man darf sich also jetzt schon auf eine Stunde rund um Bugs und deren Vermeidung freuen oder sich wahlweise davor fürchten. Ich hab viel zu erzählen.
• Per Zufall bin ich hierüber gestolpert: Wie man ein guter Java-Programmierer wird. Ich fürchte, da ist was Wahres dran. Gilt natürlich auch für andere Sprachen und Bereiche. Nun, was soll ich sagen? Ich bin 23 und hab vor knapp 10 Jahren angefangen zu programmieren. Und B.Sc. bin ich auch schon. Also weiter gehts…
• Die aktuelle Liste der Top 25 Sicherheitslücken. Erschreckend, dass SQL-Injection immer noch ganz vorne ist.
• In C# kann man Interfaces auf zwei Arten implementieren. Entweder implizit oder explizit, d.h. entweder man implementiert einfach passende Methoden oder man spezifiziert genau, dass die Implementierung ausschließlich für dieses Interface gedacht ist. Das bedeutet, es ist möglich, dass eine Methode von einem bestimmten Interface aus zugänglich ist, von der eigentlichen Klassenreferenz aber nicht. Das klingt erstmal sehr merkwürdig, hat aber seine Vorteile. Es bietet nämlich die Möglichkeit, Methoden, die nur für ein bestimmtes Interface relevant sind, vor anderen Benutzern zu verbergen. Das ist dann quasi eine weitere Möglichkeit der Kapselung. Nick Hodges zeigt in einem Blog-Post, dass das auch in Delphi möglich ist. Bei Delphi kommt noch ein weiterer Punkt dazu: Wenn man in Delphi Interfaces verwendet, sollte man diese nicht mit echten Objektreferenzen mischen (außer man weiß sehr genau, was man tut). Das hängt damit zusammen, dass Interface-Referenzen im Gegensatz zu normalen Referenzzählung implementieren. Mit diesem Ansatz kann man also quasi sicher stellen, dass man die Klassenreferenz nicht benutzt (auf der anderen Seite sollte man hier eh überlegen, ob man nicht lieber ne Factory-Methode einsetzt). Die Diskussion in den Kommentaren ist übrigens auch interessant. Darüber wie und ob man dieses Feature verwenden sollte, sind die Meinungen gespalten. Auf jeden Fall, sollte man sowas gut dokumentieren.

Delphi-Tage 2011

Momentan komm ich nicht so ganz hinter dem her, was ich mir eigentlich vorgenommen hab. Hab zur Zeit ne Menge Arbeit und so ist hier im Blog in letzter Zeit kaum was Größeres gelandet. Auch wenn ich dazu schon diverse Ideen und halbfertige Erzeugnisse hab.

Gestern bin ich jedenfalls endlich mal dazu gekommen auf den Call for Papers für die Delphi-Tage 2011 zu antworten. Wenn also alles klappt, d.h. wenn die Organisatoren meinen Vortrag haben wollen, dann bin ich am 10. September also in Köln und werde was übers Bugs erzählen und wie man sie vermeiden kann.

Letztendlich wird das nix Weltbewegendes, keine Forschung, keine neuen Erkenntnisse, dafür aber wohl hoffentlich brauchbare Praxis. Es wird da wohl nen größeren Teil über Exceptions und Assertions geben und wieder ein paar von meinen heißgeliebten Daumenregeln.

Alle Delphianer können sich also mal den 10. September rot im Kalender anstreichen. Ob um mir zu zu hören oder um mir aus dem Weg zu gehen, darf jeder selber entscheiden.

Aber warten wir erstmal ab, ob mein Vortrag überhaupt genommen wird. Da ist noch lang nix entschieden.

Gefangen, nicht gefunden! #16

Informatik – Im Weitesten Sinne

• Martin Fowler über Zertifikate
• Nochmal Martin Fowler. Diesmal über die Umsetzung von Rollen. Fowler zeigt hier, wie man auf verschiedene Art und Weise Rollen umsetzen kann. Der Artikel ist darüber hinaus augenöffnend, was den Unterschied zwischen Analyse und Design angeht.
• Wie nutzt man eigentlich Exceptions richtig? Dazu hab ich einen interessanten Artikel gefunden. Der Artikel bezieht sich auf Java, lässt sich aber leicht auf andere Sprachen übertragen.
• Den Call for Paper für die diesjährigen Delphi-Tage hab ich schon vor einiger Zeit bemerkt. Mir schwebt auch schon etwas vor. Nur muss ich endlich mal dazu kommen, was zusammen zu schreiben und abzuschicken.
• Eigentlich hab ich die ganze Zeit schon vor, über das Kreis-Ellipse-Problem zu bloggen. Allerdings hab ich dazu deutlich mehr Material gefunden, als ich bisher Zeit hatte zu sichten. Bis ich dazu komme, etwas zu schreiben, hier schonmal in Link.
• Kurz und verständlich. Die Java Collections API.
• Von der gleichen Seite: Datumswerte in Java. Hier sieht man mal wieder, was so typisch für die Java API ist: Intuitive Interfaces wurden zuerst genutzt. Die waren aber inflexibel ausgelegt. Jetzt sind die deprecated und es gibt bessere und mächtigere Interfaces. Nur sind die eben nicht mehr so intuitiv benutzbar. Die ganzen deprecated-Interfaces müllen den Namensraum zu. Jeder würde Datumsfunktionen in der Klasse Date suchen. Nur sind das eben die alten, die man nicht mehr benutzen soll… Das ist der Nachteil von Abwärtskompatibilität bzw. einer gewissen Lesart des Open-Closed-Principles: Alte Zöpfe, die niemand abschneidet. Nicht dass ich damit sagen wollte, man sollte das unbedingt tun. Das ist wie immer eine Abwägungssage. Und es zeigt, wie schwierig Frameworkdesign ist.
• Eigentlich hatte ich ja vor, ein Tutorial über OOA und OOD zu schreiben. Sieht aber momentan so aus, als käme ich nicht dazu. Vielleicht mache ich aber auch einzelne Blogartikel draus und fasse die später doch zu einem Tutorial zusammen. Mal sehen…

Anderes

• Ich lese gerade “Der Zauberhut” von Terry Pratchett. Das Buch ist echt klasse. Terry Pratchett schreibt ja generell tolle Bücher und gerade jetzt merke ich das mal wieder. Faszinierend.

The Tradeoff Game

Wie ich schon mehrfach erläutert habe, sehe ich Softwareentwicklung als das ständige Ausbalancieren von Prinzipien oder “Daumenregeln”. Es gibt eine ganze Menge solcher Daumenregeln (ich hab mal an die hundert solcher gesammelt) und ich hab vor, diese nach und nach hier mal vorzustellen.

Einige dieser Regeln ergänzen sich, manche sind spezieller als andere oder einfach nur eine andere Sichtweise auf eigentlich das selbe Prinzip. Viele aber widersprechen sich auch. Ein typisches Beispiel wären folgende beiden Prinzipien:

1. mache deine Software generisch, damit sie auch leicht mit geänderten Anforderungen klar kommt; kurz: allgemeingültig ist besser als speziell
2. mache deine Software einfach, damit sie leicht verständlich ist (KISS); kurz: einfach ist besser als kompliziert

Es wird wohl kaum jemand in Abrede stellen, dass beides wichtige Prinzipien der Softwareentwicklung sind. Wir alle wollen am liebsten einfachen Code der trotzdem sehr viel kann. In der Regel werden wir so etwas aber nicht haben können. Je generischer man versucht zu programmieren, desto komplexer wird der Code. Letztendlich streben beide Prinzipien also in unterschiedliche Richtungen. Es gilt dabei immer einen Mittelweg zu finden.

Man kann diese Daumenregeln auch als “Kräfte” bezeichnen. Dann wäre das, was wir suchen, eine Art Kräftegleichgewicht. Die Kräfte können unterschiedlich stark sein und so liegt das Gleichgewicht nicht immer in der Mitte. Außerdem gibt es meist mehr als zwei Kräfte, die es zu betrachten gilt.

Oft sind die Gewichtungen aber auch subjektiv. Manche Entwickler werden Einfachheit wichtiger finden, andere finden Generizität wichtiger. Es gibt dann mehrere “richtige” Lösungen. Aber alle werden darüber übereinstimmen, dass eine Lösung, die beide Prinzipien missachtet, eine schlechte ist. Komplizierte Software, die nur einen ganz bestimmten Spezialfall abdeckt und sich nicht auf andere Probleme anpassen lässt, wollen wir in der Regel nicht haben [1]. Wir suchen also eine Art Pareto-Optimum. Welche pareto-optimale Lösung jetzt für ein konkretes Problem gewählt werden sollte, hängt von vielen Faktoren ab. Zum einen von den konkreten Anforderungen für die zu entwickelnde Software, zum anderen aber auch projektabhängige Einflüsse wie Vorlieben, Kenntnisse und Fähigkeiten der Teammitglieder und sogar der Teamorganisation.

Dieses Ausbalancieren bezeichne ich gerne als “Tradeoff Game”. weiter lesen »

Was die OOP-Tutorials verschweigen

oder: Wie man objektorientiert denkt

Abstract

Zielgruppe: OOP-Einsteiger und -Fortgeschrittene, sowie alle, die das Gefühl haben, die OOP noch nicht ganz verstanden zu haben. Ein OOP-Tutorial sollte man aber zumindest mal gelesen haben.

Die ersten Gehversuche in der OOP fallen oft recht schwer. Und in der Tat klappt das, was dabei heraus kommt, meinst mehr schlecht als recht.
Die OOP erweitert erst einmal die Möglichkeiten, Fehler zu machen. Eine der Ursachen dafür ist, dass Objektorientierung eine andere Denkweise erfordert. Ohne diese objektorientierte Denkweise programmiert man vielleicht “prozedural mit Klassen”, nicht aber wirklich objektorientiert. Und so bleiben auch die schönen Vorteile der OOP wie Wiederverwendbarkeit und Änderbarkeit aus. Wie aber denkt man objektorientiert? Dieser Vortrag stellt einige objektorientierte Denkmuster und Prinzipien vor und zeigt, dass Objektorientierung mehr ist als Klassen und Vererbung.

Folien

Das war Thema meines Vortrags auf den diesjährigen Delphi-Tagen. Die Folien gibts wie versprochen zum Download: weiter lesen »

Delphi-Tage 2010

Die Delphi-Tage 2010 sind vorbei und ich bin wieder gut zu Hause gelandet. Hier mal ein kurzer Bericht.

Freitag

Der Freitag begann bei mir mit unfreiwilligem Frühsport in Frankfurt. Da der Zug von Mainz nach Frankfurt Verspätung hatte, musste ich zu meinem ICE rennen. Hab ihn aber gerade noch erreicht. Eine viertel Stunde später blieb dieser dann aber auch schon in Hanau stehen… wegen einer technischen “Störung”. Die Störung konnte nicht behoben werden und so war für diesen Zug erstmal Endstation in Hanau. Also eine Stunde auf den (überfüllten) Ersatzzug warten, der dann auch nochmal ne halbe Stunde Verspätung einsammelte. Am frühen Freitag Nachmittag bin ich dann aber doch noch – totz der Bahn – in Berlin angekommen.

Nachmittags habe ich mir dann die Gedächtniskirche (sehr sehenswert!) und das neue Regierungsviertel angesehen und abends gings dann aufs Schiff.

Samstag

Am Samstag war dann die eigentliche Hauptveranstaltung. Die Keynote von David I. und die anschießende Präsentation der neuen Features von Delphi XE durch Matthias Eissing, Daniel Magin und Daniel Wolf brachte IMHO keine besonders aufregenden neuen Infos. Ein 64bit-Kompiler wurde vorgeführt “Ja wir arbeiten wirklich daran” und die in Delphi XE integrierten Plugins wurden vorgestellt. Mein Eindruck von Delphi XE: Wenn man es für erwähnenswert hält, dass es nun einen neuen Button gibt, der es erlaubt, das Programm auch ohne Debugger zu starten, zeugt das nicht unbedingt von großen Fortschritten…

Nach der Kaffeepause war dann auch schon ich mit meinem Vortrag an der Reihe. Dazu gibts später nochmal nen gesonderten Blog-Post und wie versprochen auch die Folien zum Download.

Dann war auch schon das Mittagessen angesagt. Danach stellten “Daniel und Daniel” in “Pimp Up Delphi – Die besten Tools für Delphi” verschiedene IDE-Erweiterungen vor. Besonders interessant fand ich da MadExcept, sowie die Analysewerkzeuge.

Ebenfalls interessant war Arvid Winkelsdorfs Session “OOP-basierte HTTP-Server mit INDY”. Ich hab bisher nicht viel mit Indy gemacht und so hab ich mal wieder einen kleinen Einblick bekommen. Aufgrund von echten und vermeintlichen Zeitbeschränkungen konnte leider nicht allzu sehr auf die saubere Herangehensweise eingegangen werden, die ja das eigentliche Thema darstellte. Trotzdem ein lohnenswerter Vortrag.

Mal sehen, vielleicht stellen ja auch noch die anderen Referenten ihre Folien und Codebeispiele online. “Online-Updates mit Delphi” hab ich beispielsweise nicht sehen können, weil der parallel zu meinem Vortrag war. Schade, aber man kann sich natürlich nicht zweiteilen. Kollisionen sind eben unvermeidlich.

Die Organisation hat gut geklappt und die Verpflegung war auch gut (insbesondere der Nachtisch). Nur könnte man das nächstes Jahr vielleicht etwas mehr auseinander ziehen. Für den Kuchen um drei Uhr hatte ich definitiv keinen Platz mehr im Magen. Vielleicht besser nächstes Jahr die erste Kaffeepause und das Mittagessen jeweils etwas vorziehen.

Resümee

Die Delphi-Tage waren wieder ausgesprochen interessant. Wieder eine gute Mischung aus Fachvorträgen und Community-Event. Wenn möglich werde ich nächstes Jahr also natürlich wieder mit dabei sein. Allein schon um die ganzen Leute aus den Foren mal (wieder) zu sehen und nicht nur zu lesen.

Bilder

Bilder hab ich ein paar gemacht, allerdings merke ich mal, wieder, dass ich von Fotografie keine Ahnung habe und so sind keine besonderen Kunstwerke entstanden. Das, was noch einigermaßen vorzeigbar ist, hab ich mal hier eingefügt.

Gefangen, nicht gefunden! #12

Informatik

• 10 things non-technical users don’t understand about your software. Kommt natürlich stark auf die Zielgruppe drauf an. Wenn die Zielgruppe aber wirklich DAUs mit einschließt, trifft die Auflistung wohl ganz gut die möglichen Probleme. (via)
• Manchmal denke ich, dass die Java API unnötig kompliziert ist. Sie ist in Teilen wirklich sehr flexibel. Man kann damit auch komplexe Aufgaben recht schön lösen. Nur für die einfachen Aufgaben, die ständig vorkommen, braucht man eben auch ne Menge Code. Und das finde ich unschön. Um ne md5-Checksumme zu bilden reicht beispielsweise ein Funktionsaufruf bei weitem nicht aus. Da das Berechnen eines Hash-Strings aber wohl eindeutig zu den Standardaufgaben gehört, wäre hier eigentlich eine Convenience-Funktion, die einfach nur das tut, sinnvoll. Nur gibt es sie nicht. (Oder ich hab sie nicht gefunden.) Man muss ich das selbst schreiben. Was für ein Quark. Und jetzt weiß ich auch, wie sich dieses Problem nennt: Turing Tarpit.
• Die Delphi-Tage rücken näher. Die Agenda steht mittlerweile mehr oder weniger fest, denke ich. Um 12:00 Uhr bin ich an der Reihe. Leider parallel zu “Online-Updates mit Delphi”, was mich auch interessiert hätte. Murpheys Gesetz…
• Ich merk immer wieder, dass Ward’s Wiki eine wahre Fundgrube ist. Wer immer mal wissen wollte, was OO ist, findet hier, dass sich die Fachwelt darüber auch nicht einig ist. Aber es ich schon ganz interessant die einzelnen Positionen zu lesen. Ich halte es da ja tendenziell mit Nygaard. OO ist vor allem eine Denkweise und nicht irgendwelche Sprach-Features.

Anderes

• “Weil, so schließt er messerscharf, // nicht sein kann, was nicht sein darf.” Kennt jeder. Aber wo kommt das her? Da her: Die unmögliche Tatsache
• Ganz interessant: Der Pauli-Effekt.