Gerade gehört: SoftwareArchitekTOUR: Patterns in der Java-Welt. Vor einiger Zeit hab ich die ersten beiden Episoden gehört. Jetzt hab ich mir mal diese angetan.
Und natürlich kann ich mich gewisser Kommentare nicht enthalten:
- Double-Checked-Locking wird erklärt. Allerdings wird nicht darauf verwiesen, dass das Pattern kaputt ist. Zumindest wenn man kein volatile benutzt. Nähere Infos in der Wikipedia
- Es wird davon gesprochen, dass das get/set-Idiom dazu verleitet, es überzuverwenden. Also man macht überall Getter und Setter und vergisst dabei, der Klasse sinnvolle Methoden zu verpassen. Die Problematik sehe ich auch. Ich frage mich nur momentan, ob Properties wie in Delphi/C#/Ruby/etc. hier einen Einfluss haben und wenn ja welchen. Positiv oder Negativ? Ich vermute einen positiven Einfluss, bin mir da aber nicht ganz sicher.
- Immutability wird IMHO leider schlecht erklärt. Es geht natürlich nicht nur darum, dass Objekte mit gleichem Wert gleich sind, sondern auch, dass die Objekte (mehr oder weniger) zustandslos realisiert werden.
- DependencyInjection hätte ich wahrscheinlich nicht verstanden, wenn ich nicht schon wüsste, was es ist. Generell scheint es mir so zu sein, dass der Podcast nur einen groben Überblick und ein paar Buzzwords liefert. Das hört sich jetzt wie vernichtende Kritik an, aber so ist es nicht gemeint. Überblick geben ist gut. Viel mehr kann man in ner dreiviertel Stunde auch nur schwer abhandeln. Man darf nur nicht mit falschen Erwartungen an den Podcast rangehen.
- Zu Multiple Dispatch hab ich schonmal was geschrieben.
Joshua Bloch hatte vermutlich schon die ein oder andere schlechte Idee. Wahrscheinlich sogar ein paar richtig bescheuerte Ideen. Und genau deshalb hat er Ahnung.
In der Java API stecken ne ganze Menge blöde Ideen, aber auch sehr gute. Typischerweise kamen zuerst die blöden Ideen wie die ursprüngliche Implementierung der Date-Klasse oder die Idee Stack von Vector abzuleiten und dann die guten, die leider etwas spät dran sind, sodass die dann nur noch die Notsitze im Namensraum gekriegt haben.
Wie viel davon Joshua Bloch nun selbst verbrochen hat, weiß ich nicht. Jedenfalls gehört er deshalb zu den Leuten, die Ahnung vom API-Design haben. Meiner Meinung nach lernt man nur aus Fehlern wirklich gut. Entweder aus den eigenen oder aus denen von anderen. Wer lieber aus den Fehlern von anderen lernen will, sollte sich vielleicht mal seinen Vortrag “How To Design A Good API and Why it Matters” ansehen. Dort beschreibt er nämlich genau das: Was man so alles falsch gemacht hat, wie man es besser machen kann und warum das nicht nur für API-Designer relevant ist, sondern (in abgeschwächter Form) für jeden Entwickler. Sehr empfehlenswert.
Den Vortrag gibts in mehreren Varianten:
Besonders gut gefallen mir die Beispiele. Da ich gerade selbst für meinen Vortrag Beispiele hab finden müssen, weiß ich, dass das viel mehr Arbeit ist, als man vielleicht denkt.
Überblick
Motivation
Es soll vorkommen, dass man in der Softwareentwicklung Probleme lösen muss. Und es soll vorkommen, dass man ein Problem, dass man schonmal gelöst hatte, nochmal lösen muss. Und es soll vorkommen, dass sich manche Probleme ähneln. Typischerweise versucht man, wenn man ein Problem zum zweiten Mal lösen muss, schneller zu sein als beim ersten Mal. Das nennt sich “lernen”.
Aber es gibt noch eine weitere Möglichkeit, beim zweitem Mal Arbeit zu sparen: Wiederverwendung. Besteht die Lösung eines Problems in einem Stück Code, dann kann man diesen verallgemeinern (parametrisieren) und beim zweiten Mal einfach hernehmen und benutzen. Das Ergebnis ist dann eine Prozedur, eine Klasse oder allgemein: ein Modul.
Aber auch, wenn die Lösung nicht in einem Stück Code besteht, sondern in einer bestimmten Herangehensweise, einer bestimmten Strukturierung oder Idee, so kann man sie wiederverwenden. Das Gegenstück zum Modul, dem wiederverwendeten Code, ist das Pattern bzw. Muster, sozusagen die wiederverwendete Idee. weiter lesen »
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.
Ich hatte vor einiger Zeit versprochen, noch etwas über Parsing zu schreiben bzw. über die prinzipielle Herangehensweise an Parsing-Probleme. Ich bin da selbst kein Experte und hab die zugehörige Vorlesung zum Compilerbau auch noch nicht gehört. Allein schon aus diesem Grund werde ich nicht sehr ins Detail gehen, sondern möglichst einfach einen Überblick geben. Wer mehr wissen möchte, sollte sich in die passende Vorlesung setzen und/oder ein einschlägiges Buch lesen.
Parsing bzw. Compilerbau ist ein sehr gut erforschtes Gebiet der Informatik. Damit beschäftigt man sich schon seit Ewigkeiten. Dementsprechend gibt es da sehr viel Kompliziertes, Detailliertes und auch Nützliches. Der klassische Compilerbau hat sich dabei auf verschiedene Klassifikationen von Grammatiken gestürzt und in der Tat ist das ein Ansatz, der oft sehr hilfreich, weil sehr systematisch ist. In der Praxis will man aber nicht immer einen Compiler schreiben (oder ähnlich komplexe Aufgaben lösen) und so gibt es in der Praxis noch ein paar andere Ansätze, die teilweise ihre Wurzeln zwar ebenfalls im Compilerbau haben, aber dennoch anders funktionieren. Im Folgenden werde ich über alles, was mir so an Ansätzen einfällt, einen Überblick geben und die prinzipielle Herangehensweise erläutern. weiter lesen »
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.
Software-Entwicklung | Christian | 
19. September 2011 20:50 | 
Kommentare (0) 
