Dariusz quatscht : Coding

Die Qual der Wahl – Blogengines

dparys — Tue, 01 Sep 2009 18:28:47 GMT

In letzter Zeit spiele ich mit dem Gedanken meinen Blog umzuziehen. Nicht komplett, eigentlich nur einen Teil. Alles andere bleibt hier, wie gehabt. Doch das Vorhaben ist gar nicht so einfach wie ich Anfangs dachte. Die Kriterien die ich an eine eigene Hosting Lösung habe sind überschaubar: einfache Anpassparkeit, Erweiterungsfähig um z.B. neue Funktionalität zu implementieren, Verwaltungsseiten um Kommentare und Beiträge im Web zu editieren und zu guter Letzt eine Codebasis in der ich mich schnell zurecht finde. Die Anpassbarkeit wäre auch im Code für mich ok, voraussgesetzt es ist eine einfach zu verstehende Codebasis. Mein derzeitiger Blog gibt mir nicht die Möglichkeit mal kurz einen neuen Trend zu implementieren bzw. auch nur per Template einzufügen. Die Codebasis ist alt und ein Update steht noch aus und ist derzeit auch nicht angekündigt. Also habe ich verschiedene Engines in Betracht gezogen.

Wordpress

Mein Kollege Oliver Scheer ist begeistert von Wordpress. Einfache Installation, einfache Anpassbarkeit, gute Themes und erweitern kann man das ganze auch – vorausgesetzt – man hat die Lust und die Muse sich mit PHP auseinanderzusetzen. Nix gegen PHP, aber ich komme jetzt schon mit viel zu vielen Technologien in Kontakt und da möchte ich mir die Einarbeitung, bzw. alleine das Arbeiten damit ersparen. Sonst wäre Wordpress in Sachen Funktionalität und Themes meine erste Wahl geworden.

dasBlog

Der Klassiker. Ich erinnere mich immer noch, als wäre es erst gestern gewesen, wie Clemens auf einem CLIP Meeting der Community seine 60.000 Zeilen Code geschenkt hat. Clemens hat damals die Engine von Chris Anderson – Blogx – als Grundlage für dasBlog verwendet. Am Anfang gab es noch keine SQL Unterstützung aber mittlerweile ist das gesamte Softwarepaket zu einem richtigen Monster ausgewachsen welches man sich auf http://dasblog.codeplex.com/ besorgen kann. An für sich erfüllt dasBlog die Kriterien der Anpassparkeit, Erweiterbarkeit und sogar die Codebasis ist mittlerweile auf .NET 2.0, doch irgendwie werde ich nicht warm damit. Das mag an der ersten Erfahrung liegen. Ich habe keinen IIS auf meiner Maschine installiert doch dasBlog ist wie ein Biest und Redirected an manchen Stellen von http://localhost:1234 –> http://localhost. Sprich, wer nicht gleich einige Zeit in die Codebasis stecken möchte, sollte einen IIS irgendwo zur Verfügung haben, hätte ich zwar, aber eben nicht auf allen Entwicklermaschinen.

BlogEngine.NET 1.5

In aller Munde in den letzten Monaten und vom Hören – Sagen, mein Favorit. Die Codebasis ist moderner, das Paket kommt mit ein paar mittelmässigen Themes und vom Aufbau her ist alles recht kompakt. Daraufhin habe ich angefangen einige Experimente mit der Engine zu machen und ja, man könnte recht schnell was hinbasteln. Und ich habe auch irgendwie das Gefühl das es sich um basteln handelt. Trotz des Bastelgefühls arbeite ich mal mit der Engine weiter.

Da stehe ich nun mit einer ersten Version meines Experiments und frage mich wie ich nun meine bisherigen Blog Posts in die Engine bekomme – BlogML ist hier das Zauberwort. BlogML erlaubt es Blogs zu exportieren und in andere Engines zu importieren. Vorausgesetzt beide Blogengines unterstützen dieses Format. BlogML ist bei der BlogEngine.NET 1.5 dabei. Cool. Doch nach einigen Suchen für meinen momentanen Blog stelle ich fest das der Community Server über ein Dashboard Server Control für BlogML erweitert werden kann und bei meinem Blog gibt es dieses Control nicht. Auch bin ich nicht der Admin der Maschine. Keine Chance also.

Komme ich nicht drumherum einen RSS Exporter –> BlogML zu schreiben? Auf Codeplex gibt es zwar einen allerdings nicht für die Community Server Engine in der Version in welcher die MSDN Blogs gehostet sind. “Vielleicht sind ja die alten Posts auch auf dem alten Blog gut aufgehoben”, denke ich mir dann.

Wie gesagt, ich probiere einige Sachen mit der BlogEngine.NET 1.5 aus, beim Anpassen stelle ich fest das es keine Verwaltungsseite für Blogposts gibt. Vielleicht habe ich nur was übersehen, ich mache weiter. Ich suche nach Themes, finde eigentlich nichts was mir gefällt, also mache ich mir selbst eines. Nun, was soll ich sagen, ich komme schon klar mit dem Konzept der Usercontrols, aber es ist mir irgendwie zu frickelig. Warum? Weil ich die Engine nicht so gut kenne und mir erst noch das Widget Control und dessen CSS Styles reinziehen mussl. Das einarbeiten in den Source ist ok, aber wie immer nerven mich die Kommentare. Vor allem wenn diese einfach nur Platz im Sourcefenster wegnehmen und keinen, wirklich keinen Mehrwert liefern.

Eine eigene Engine?

Vor einigen Tagen hat Rob Connery auf seinem Blog über ein mögliches Aushängeschild von Entwicklern geschrieben: Be a good Jedi: Build your own Blog. Eigentlich ist es unsinnig eine eigene Blogengine zu schreiben, es gibt doch schon einen Haufen, auf der anderen Seite ist es auch unsinnig sich lange in den Code von anderen reinzuarbeiten um nur einen Blog zu hosten. Vielleicht sind meine Ansprüche zu hoch? Eigentlich nicht. Vielleicht sind die Engines nur aufgeblasen weil diese eben eine Masse an Nutzern bedienen sollen. dasBlog und die BlogEngine.NET sind Softwarepakete die sowohl Benutzern wie auch Entwicklern gefallen sollen, von denen ich nur einen Teil benötige. Um diesen Teil einfach zu erhalten muss ich aber einen gewissen Aufwand reinstecken, da die Anpassbarkeit nicht so einfach ist wie bei Wordpress (ich rede hierbei nicht von der Erweiterung durch PHP).

Vielleicht macht es doch Sinn eine eigene Engine zu schreiben? Warum stelle ich mir eigentlich diese Frage? Nein, macht es nicht. Zumindest nicht für mich. Aber ich kann gut nachvollziehen das Entwickler schnell mal daran denken. Ist ja eigentlich für eine Custom Engine auch relative einfach die Grundfunktionalität zu bauen. Man benötigt ja dann keine ausgeklügelte UI um Anpassungen zu machen, denn man kennt ja die Engine In- und Auswendig.

Softwareentwickler neigen gerne ein Produkt oder ein Framework wieder neu zu erfinden, weil eben der Knopf A nicht auf Position B liegt sondern auf Position C und der Code nicht die Fancy Lambdas aus .NET 3.5 nutzt. Zählt mal alleine die Anzahl an ORM Frameworks die es draußen im Markt und vor allem im Open Source Bereich gibt, so weiß man gar nicht so recht welche man alle Testen soll. Alle haben Vor- und Nachteile, doch überwiegen bei allen die Nachteile so stark das man gleich selbst eines schreiben muß?

Meinem eigentlichen Ziel, ein Blog auf einem eigenen Server zu hosten und dort Teile anpassbar zu haben bin ich zumindest ein bißchen näher gekommen (ca. 1%). Wahrscheinlich werde ich die BlogEngine.NET dazu nehmen, aber vielleicht überkommt es mich ja noch und ich störe mich auch nicht an PHP dann wäre Wordpress wohl die Wahl.

Eine eigene Engine schreiben? Nochmals nein, der Teufel steckt nachher im Detail. Es sei denn es gäbe ein Framework das mir lediglich die Grundkomponenten zur Verfügung stellt. RSS/ATOM Feed Rendering, Ping- und Trackback Services oder ein Domain Modell dass sich lediglich auf die Pflichtattribute von Feeds begrenzt und alles andere optional hinzufügen lassen würde. Ein kleines, übersichtliches Framework, das könnte man als Basis nimmt und wirklich nur das notwendigste zur Verfügung stellt. Damit man die rudimentären Dinge nicht nochmals schreiben müsste. Dann, dann vielleicht.

TechTalk Dezember 2009: Anwendungsentwicklung mit Visual Studio 2010

dparys — Fri, 31 Jul 2009 12:05:52 GMT

Erst im Juni habe ich einen TechTalk hinter mir und schon steht mein nächster an. Dieses mal jedoch nicht über einen Monat gezogen sondern in einer Woche werden 5 Städte besucht und mein Kollege Christian Binder wird auch mit von der Partie sein.

In Visual Studio 2010 kommen so viele neue Elemente dazu das wir einfach in diesem TechTalk verschiedene Aspekte live im Coding demonstrieren wollen und auf hoffentlich viele Fragen eingehen dürfen. Ganz nach dem Motto: “Keine Slides! Nur Code!”

Hier der Auszug von der MSDN TechTalk Anmeldeseite:

Der letzte MSDN TechTalk in diesem Jahr nimmt Sie mit auf eine Reise zur nächsten Version von Visual Studio: Visual Studio 2010. Dabei werden Christian Binder und Dariusz Parys die interessantesten Aspekte der neuen Entwicklungsumgebung vorstellen: von Verbesserungen in den einzelnen Frameworks bis hin zu neuen Möglichkeiten in den Application Lifecycle Management Tools, die das Testen und die Entwicklung im Team einfacher machen, wird dieser TechTalk die verschiedenen Aspekte mit Hilfe von Live Codings demonstrieren. Das heißt ganz klar: Keine Slides! Nur Code!

Die Termine:

An manchen Terminen werden wir vermutlich deutlich überziehen, das dürfte Karlsruhe, Berlin und München sein. In Köln und Hamburg sind wir leider an die Öffnungszeiten des Microsoft Office gebunden.

Ich freue mich schon auf viele Teilnehmer und Fragen, bis dann!

Link: Offizielle TechTalk Anmeldeseite

Community: Stefan Lieser über Clean Code Developer

dparys — Tue, 28 Jul 2009 08:38:16 GMT

Auf dem .NET Open Space Süd 2009 in Ulm hatte ich die Gelegenheit Stefan Lieser kennenzulernen. Stefan und Ralf Westphal haben die Clean Code Developer Initiative ins Leben gerufen. Ich wollte von Stefan genauer wissen was es damit auf sich hat und habe ihn einfach vor die Kamera gezerrt und ihn befragt. Warum Stefan zwei Armbänder trägt und überhaupt Armbänder trägt, das erklärt er auch im Interview. Viel Spaß beim reinschauen!

Am Anfang war ein Band…

dparys — Thu, 25 Jun 2009 10:33:15 GMT

…oder wie alles Anfing. In diesem Video erzählt Bill Gates die Entstehung von ALTAIR BASIC. Ein interessanter Beitrag von Lisa Feigenbaum aus der Reihe The History of Microsoft.

C# Lambdas und die Lesbarkeit von Source Code

dparys — Tue, 16 Jun 2009 09:43:59 GMT

Auf dem heutigen TechTalk in Köln zum Thema Parallel Computing ist eine rege Diskussion zum Thema Lambdas in C# entstanden. Beim Vorstellen der .NET Klasse Parallel aus dem System.Threading Namespace in .NET 4.0 habe ich neben den einfachen Parallel.Invoke Beispiel auch eine Monte Carlo PI Simulation gezeigt. Dabei wurde die Funktion Parallel.For<T> benutzt.

Mit dieser Funktion lassen sich Schleifen parallelisieren und entsprechend die Ergebnisse der einzelnen Tasks zusammenfassen. Zum Beispiel kann man diese For Schleife

   1: int total = 0;

   2: for (int i = 0; i < 10; i++)

   3: {

   4:     total += 1;

   5: }

folgendermaßen mittels der Klasse Parallel auf mehrere Prozessorkerne verteilen:

   1: Parallel.For<int>(0, 10, () => 0, (i, pls, subtotal) =>

   2:     {

   3:         subtotal += 1;

   4:         return subtotal;

   5:     },

   6:     (x) => { Interlocked.Add(ref total, x); });

(Hinweis: Das ist nur ein Beispiel und ist den Aufwand nicht wert parallel verarbeitet zu werden!)

Nun ist der parallelisierte Code nicht so leicht lesbar. Was für hitzige Diskussionen sorgte. Ich habe auch ein wenig provoziert und auch darauf hingewiesen das der Code nicht unbedingt gleich zu verstehen ist. Was passiert da eigentlich?

Die Parallel.For<T> Methode so wie ich sie oben benutze bekommt 3 Lambda Ausdrücke mit. Einmal die Initialisierung des einzelnen Threads mittels der Funktion () => 0. Diese Lambda Schreibweise ist die Abkürzung für Action ohne Parameter. Der zweite Lambda Ausdruck hat gleich 3 Parameter, einmal die Laufvariable i, dann eine Variable mit dem Namen pls und schliesslich die letzte Variable subtotal. Interessant ist, das man nicht anhand des Codes erkennen kann was diese einzelnen Variablen darstellen. Vielmehr muss man mittels Intellisense oder Dokumentation nachschauen um welche Typen es sich hier genau handelt. i ist ein int, pls ist ParallelLoopState und subtotal wieder ein int und ein Rückgabewert! Letztlich mapped diese Lambda auf die Deklaration Func<int,ParallelLoopState,out int>. Ist schon gewöhnungsbedürftig. Die dritte Lambda ist schliesslich für die Reduktion zuständig, das Zusammenführen der einzelnen Ausführungspfade zur Gesamtvariable total. Die Variable x an dieser Stelle ist der Rückgabewert der zweiten Lamdba subtotal. Eigentlich recht einfach wenn man weiss wie Paralle.For<T> implementiert ist.

Genau hier liegt das Problem. So mächtig Lambda Ausdrücke auch sein mögen, Sie bergen auch viele Risiken. Wenn Klassen Funktionen implementieren die vor lauter Action und Func Parameter nur so strotzen, so darf man sicher sein dass Lambdas an dieser Stelle eingesetzt werden. Das wiederrum macht den Code nicht gleich intuitiv lesbar. Beschäftigt man sich gerade mit der API so ist es ein leichtes zu verstehen was die Implementierung bedeutet. Aber wie sieht es aus wenn man sich eine Weile nicht mit dieser API beschäftigt und dann nach 2-3 Monaten mal wieder drauf schaut? Ich wette man muss dann kurz inne halten und sich vielleicht sogar die Dokumentation nochmals lesen.

Insofern ist der Einwand der zwei Teilnehmer heute irgendwie schon berechtigt, auf der anderen Seite ist eine anderen Lösung womöglich gar nicht so trivial. Natürlich könnte man das ganze auch in einem Fluent Interface Ansatz als API zur Verfügung stellen, vielleicht so,

   1: FluentParallel.For

   2:     .From(0)

   3:     .To(10)

   4:     .ExecuteLoopBody(

   5:         (subtotal) =>

   6:         {

   7:             subtotal += 1; return subtotal;

   8:         })

   9:     .Reduce(

  10:         (subtotal) =>

  11:         {

  12:             Interlocked.Add(ref total, subtotal);

  13:         })

  14:     .Wait();

doch wirklich etwas gewonnen hat man hier nicht unbedingt. Die API könnte ein paar allgemeine Annahmen einfach implementieren, trotzdem wird beim Einsatz der Lambdas die Problematik mit den Übergabeparametern nicht gelöst. Man erkennt den Typen nach wie vor nicht und bei komplexeren Loop Bodies wäre damit auch dieser Ansatz nicht unbedingt lesbarer.

Lambdas bergen Risiken was die Lesbarkeit des Codes angeht und damit Hand in Hand auch dessen Wartbarkeit. Wie seht Ihr den Einsatz von Lambdas?

Projekt Blog Poll – Entity Framework Revisited und die Folgen bisher

dparys — Mon, 15 Jun 2009 11:23:27 GMT

Das Projekt Blog Poll ist nun wieder beim Entity Framework angekommen. Dieses mal werden die Entitäten auf die eigenen Objekte gemapped. Jetzt werden sich vermutlich einige Leute fragen, warum mappe ich auf eigene Objekte? Dann lässt sich doch das ADO.NET Data Services Framework nicht so einfach nutzen. Bei einem eigenen Objekt Modell muss man zusätzliche Schnittstellen implementieren! Stimmt. Aber ich werde im folgenden Projekt die ADO.NET Data Services auch nicht final benutzen. Ich habe in meinem Test Prototypen ein Problem festgestellt das ich noch nicht so hundertprozentig eingrenzen konnte. Das Problem ist beim Hosten von Silverlight Anwendungen über Cross-Domain Grenzen mit dem Zugriff auf die ADO.NET Data Services. Der Datenzugriff funktioniert in dem Szenario nicht so wie er soll. Insofern werde ich das Repository durch eine WCF Service Schicht kapseln, diese hat kein Probleme mit der Cross-Domain Verteilung der Anwendung.

Für alle die, die noch nicht so richtig ins Projekt reingeschaut haben, gibt es hier nochmal die komplette Serie verlinkt.

Projekt Blog Poll – Anforderungen (Teil 1)

Projekt Blog Poll – Technisches Design (Teil 2)

Projekt Blog Poll – Datenbankschema (Teil 3)

Projekt Blog Poll – Entity Framework Repository (Teil 4)

Projekt Blog Poll – Domain Model (Teil 5)

Projekt Blog Poll – Specification (Teil 6)

Projekt Blog Poll – Mock Repository (Teil 7)

So, viel Spaß beim 8. Teil.

Update: Jetzt müsste das Video auch in besserer Qualität zu sehen sein.

Projekt Blog Poll – Mock Repository

dparys — Mon, 15 Jun 2009 11:10:55 GMT

Damit die Tests zusammen mit dem Domänen Modell wieder kompilieren, schreibe ich in dieser Folge ein Mock Repository.

Projekt Blog Poll – Domain Model

dparys — Wed, 27 May 2009 18:03:14 GMT

Nach den Erkenntnissen in Teil 4, werden die weiteren Repository Implementierungen vorbereitet. Was hierzu fehlt ist ein Domänen Modell das in diesem 5. Teil seinen Anfang findet.

Viel Spaß beim reinschauen.

Projekt Blog Poll – Entity Framework Repository

dparys — Mon, 25 May 2009 11:08:42 GMT

Im 4. Teil der Serie zum Projekt Blog Poll geht es nun in die erste Implementierung. Ein Repository soll erstellt werden. Die erste Technologie die ich benutze ist das Entity Framework. Und wie mit jeder neuen Technologie ist auch bei dieser die ein oder andere Fragestellung zu lösen.

Projekt Blog Poll – Technisches Design

dparys — Fri, 15 May 2009 10:01:26 GMT

Im zweiten Teil versuche ich die Anforderungen technisch Aufzubereiten . Natürlich habe ich mit der ersten Testimplementierung schon so eine Art Marschrichtung im Kopf, doch ich versuche das ganze objektiv zu erörtern. Ob die Entscheidungen die ich hier treffe später auch die richtigen sind wird die Zeit zeigen.

Der Ton ist in diesem und im nächsten Teil noch nicht so toll, ab dem 4. ist es deutlich besser.

Projekt Blog Poll – Anforderungen

dparys — Thu, 14 May 2009 10:48:43 GMT

Vor längerer Zeit habe ich die Frage gestellt ob der FC Bayern München noch Deutscher Meister werden kann. Die Umfrage ist mit einer Silverlight 2 Anwendung erstellt worden. Die Anwendung habe ich nun als Grundlage genommen um eine Screencast Serie auf Channel 9 zu publizieren. Das ganze heißt Projekt: Blog Poll und zeigt wie die Anwendung entwickelt wird.

Viel Spaß beim reinschauen.

Wer PEX mag, wird Code Contracts lieben!

dparys — Tue, 24 Feb 2009 08:30:24 GMT

Auf Microsoft DevLabs ist ein weiterer Baustein zum Thema Code Qualität erschienen: Code Contracts. Ein Projekt das von Microsoft Research entwickelt wurde, findet so langsam seinen Weg in den Produktionsalltag.

Was kann man mit Code Contracts machen? Man definiert notwendige Bedingungen für die Anwendung einer beliebigen API Schnittstelle im Code, z.B.

   1: public int Function( int parameter )

   2: {

   3:     Contract.Requires( parameter > 0 );

   4:     // ...

   5: }

Neben der Möglichkeit zur Laufzeit Prüfungen einzubauen, kann man auch statische Prüfungen durchführen und somit auch zur Compile-Zeit wichtige Hinweise auf mögliche Probleme erhalten. Code Contracts bietet für PEX eine sehr gute Hilfe Tests noch effizienter zu erstellen.

Auf der Webseite gibt es unten rechts noch ein nettes Einführungsvideo.

Link: Microsoft DevLabs Code Contracts

Coding 4 Fun: Slide Tweet 0.1

dparys — Tue, 10 Feb 2009 17:24:05 GMT

What is Slide Tweet? A Powerpoint Add-In twittering slide titles. If you are not familiar with http://twitter.com I suggest to read the post “How to Twitter – First Steps and a Twitter Glossary” from Scott Hanselman. Why do I want to have an add-in for powerpoint twittering slide titles? Well, I had an idea and I will test it in the next talk I give. The idea is simpel to integrate the audience through Twitter while presenting content.

People can follow the tag specified in the beginning of the presentation and make comments, retweet or discuss the slide topic presented currently. Maybe I will use this to answer questions coming through twitter during the presentation, I’m not sure yet.

Here are some screenshots how this works. First you load any powerpoint you want to present and start the presentation. After this you will be asked if you want to twitter this deck.

After specifying credentials and the tag to use for the tweets, you are ready to go. During presentation slide titles will be twittered with the specified tag. The audience is able to follow this tag. Let’s assume we have a tag which is called #gac09. You can basically follow this tag using the twitter search functionality or any other twitter client able to search for tags.

The results will be shown and refreshed if new content for this tag is available.

You will see all tweets using the tag and not only the tweets by your presentation but also any tweets using the tag, replying on your tweets.

The audience could interact among each other and give also feedback via Twitter (at least this is the idea I had). That said, it makes sense to specify one or multiple tags to make the presentation unique (please no UUID).

I will see how it works on my next talk.

If you are a presenter and would like to try out this add-in you can. I have posted a resource page on my code gallery with the solution file: Slide Tweet. Please note that you need Visual Studio 2008 and Visual Studio Tools for Office and Powerpoint 2007 to run this sample. I have no really good setup so far, neither good error handling. Therefore enjoy with care.

One design decision I made. I always call to Twitter asynchronously with one exception. The last slide is posted synchronously, just to ensure that every call was made (so I even don’t utilize the callbacks).

Have fun and feedback welcome!

Clean Code – Mein Versuch daran zu arbeiten

dparys — Tue, 20 Jan 2009 11:57:43 GMT

Ich finde die Idee vom Clean Code Developer Schick. Wer möchte schliesslich nicht in seinem tun besser werden? Ich habe angefangen mich mit dem Buch Clean Code zu beschäftigen. Heute beim weiter arbeiten an meinem Code habe ich folgende Funktion entdeckt:

   1: private bool ProxyIsValid()

   2: {

   3:     return (proxy != null && proxy.State == CommunicationState.Opened) ? true : false;

   4: }

Eine kurze Funktion die Aussagekräftig genug ist, oder? Doch irgendwie stört mich etwas daran.

Ich fange mal mit dem Namen an. ProxyIsValid(). Vielleicht sollte ich es lieber IsProxyValid() nennen? Schliesslich prüfe ich bevor ich auf den Proxy zugreife ob ich es tun kann. Doch was macht die Funktion.

Zum einen prüft sie ob die Instanz nicht null ist und dann prüft sie noch ob die Instanz einen Kommunikationskanal geöffnet hat. Sind eigentlich zwei Prüfungen, der Name IsProxyValid() ist zwar nich generell falsch doch viel zu generisch. Ich benenne die Funktion um in IsProxyValidAndOpen(). Anbei der Code der momentanen Funktion und ein Aufruf der Funktion aus einer anderen heraus:

   1: private void NotifyTicketAvailable(Ticket ticket)

   2: {

   3:     if (IsProxyValidAndOpen())

   4:     {

   5:         proxy.NewTicketAvailable(

   6:             new NewTicketAvailableRequest { Ticket = ticket });

   7:     }

   8: }

9:

  10: private bool IsProxyValidAndOpen()

  11: {

  12:     return (proxy != null && proxy.State == CommunicationState.Opened)

  13:         ? true : false;

  14: }

Doch irgendwie stören mich noch die direkten Abfragen auf die Instanz und die Eigenschaft. Sollte man statt proxy != null eine Funktion implementieren? Sollte man proxy.State == CommunicationState.Opened kapseln? Ich mache es einfach mal und schaue mir dann das Ergebnis im Code an:

   1: private void NotifyTicketAvailable(Ticket ticket)

   2: {

   3:     if (IsProxyValidAndOpen())

   4:     {

   5:         proxy.NewTicketAvailable(

   6:             new NewTicketAvailableRequest { Ticket = ticket });

   7:     }

   8: }

9:

  10: private bool IsProxyValidAndOpen()

  11: {

  12:     return (IsProxyValid() && IsProxyOpen())

  13:         ? true : false;

  14: }

15:

  16: private bool IsProxyOpen()

  17: {

  18:     return proxy.State == CommunicationState.Opened;

  19: }

20:

  21: private bool IsProxyValid()

  22: {

  23:     return proxy != null;

  24: }

Liest sich zumindest gut. Doch ist es richtig? Irgendwie hat sich ein neuer Fehler eingeschlichen. Ich habe, muss ich gestehen, keine Unit Tests für meinen Code. Ich kann die Änderungen jetzt nicht validieren. Da ist noch ein großes TODO das an mich selbst geht. Schreibe Unit Tests, schreibe Unit Tests, schreibe Unit Tests. Doch den Fehler sieht man bestimmt. Jemand könnte die Methode IsProxyOpen() aufrufen ohne das es eine Instanz Proxy gibt. Also wieder refactoring, ich schreibe die Methode IsProxyOpen() um:

   1: private bool IsProxyOpen()

   2: {

   3:     return IsProxyValid()

   4:         ? proxy.State == CommunicationState.Opened : false;

   5: }

Hmmm… Ich drehe mich im Kreis scheint mir. Ist nun die Namensgebung IsProxyOpen() noch korrekt? Ich sage jetzt einfach mal ja. Also passe ich noch die Methode IsProxyValidAndOpen() an:

   1: private bool IsProxyValidAndOpen()

   2: {

   3:     return IsProxyOpen();

   4: }

Haleluja. Ne, doch nicht. Jetzt scheint es irgendwie auszuarten. Ich habe eine Funktion die heißt IsProxyValidAndOpen() und die gibt einfach den Return-Wert von IsProxyOpen() zurück. Das ist so nicht im Sinne des Erfinders, noch ist es lesbar, noch wartbar.

Wo liegt denn das Problem. Ich habe es. Die Namensgebung ist doch das Problem. Mein Denken darüber vor dem Umschreiben der Methode war bereits im Bilde, ich habe mich gewehrt, doch nun sehe ich es bildlich vorm Auge. Die Namen sind Crap!

Welchen Namen wähle ich nun, ich denke ich schaue mir nochmal alle momentanen Funktionen auf einmal an:

   1: private void NotifyTicketAvailable(Ticket ticket)

   2: {

   3:     if (IsProxyValidAndOpen())

   4:     {

   5:         proxy.NewTicketAvailable(

   6:             new NewTicketAvailableRequest { Ticket = ticket });

   7:     }

   8: }

9:

  10: private bool IsProxyValidAndOpen()

  11: {

  12:     return IsProxyOpen();

  13: }

14:

  15: private bool IsProxyOpen()

  16: {

  17:     return IsProxyValid()

  18:         ? proxy.State == CommunicationState.Opened : false;

  19: }

20:

  21: private bool IsProxyValid()

  22: {

  23:     return proxy != null;

  24: }

Da, Zeile 21! Sollte nicht IsProxyValid() in IsProxyValidInstance() oder so umbenannt werden? Und IsProxyValidAndOpen() in IsProxyReadyForCommunication()? Bin mir nicht sicher. Ich sollte konsistent bleiben. Als nicht Ready und Valid mit ein und der selben Bedeutung ausstatten. Ich würde gerne meine ursprüngliche Bezeichnung IsProxyValid() für einen gültigen, voll initialisierten Proxy benutzen, der sofort zum kommunizieren genutzt werden kann. Dann würde ich IsProxyValid() einfach in IsProxyInstance() umbenennen.

   1: private void NotifyTicketAvailable(Ticket ticket)

   2: {

   3:     if (IsProxyValid())

   4:     {

   5:         proxy.NewTicketAvailable(

   6:             new NewTicketAvailableRequest { Ticket = ticket });

   7:     }

   8: }

9:

  10: private bool IsProxyValid()

  11: {

  12:     return IsProxyOpen();

  13: }

14:

  15: private bool IsProxyOpen()

  16: {

  17:     return IsProxyInstance()

  18:         ? proxy.State == CommunicationState.Opened : false;

  19: }

20:

  21: private bool IsProxyInstance()

  22: {

  23:     return proxy != null;

  24: }

Bin ich jetzt glücklich. Nein, jetzt erkenne ich das die Prüfung des Proxies gar nicht die Aufgabe dieser Klasse ist, sondern mir der Proxy einfach eine Funktion zur Verfügung stellen sollte. In etwa so:

   1: private void NotifyTicketAvailable(Ticket ticket)

   2: {

   3:     if (proxy.IsValid())

   4:     {

   5:         proxy.NewTicketAvailable(

   6:             new NewTicketAvailableRequest { Ticket = ticket });

   7:     }

   8: }

Was meint Ihr? Hat sich der Aufwand gelohnt?