Cake.Compression AddIn

Cake (C# Make) ist ein plattformübergreifendes Build Automatisierungssystem, welches es dank seiner umfangreichen API ermöglicht, einfache bis komplexe Build Skripte schnell zu erstellen. Man kann die Skripte auch durch eigene oder vorhandene AddIns erweitern.

Für ein Skript benötige ich die Möglichkeit GZip Archive zu erstellen. Von Haus aus bietet Cake jedoch nur die native .Net Zip Funktionalität an und es gab auch kein entsprechendes AddIn. Daher habe ich auf Basis der SharpZipLib das Cake.Compression AddIn erstellt, welches Funktionalität für die Erstellung von (Tar) BZip2, GZip und Zip Archiven bietet.

Das Package ist über NuGet und der Quellcode über GitHub/Bitbucket verfügbar.

Codeanalyse Tools Atomiq und Nitriq

Codeanalyse Tools sind bei der Software Entwicklung sehr hilfreich, den sie können auf Schwächen aufmerksam machen, die auf den ersten Blick nicht gleich erkennbar sind. Mit Atomiq und Nitriq gibt es zwei dieser hilfreichen Tools als Freeware.

Atomiq analysiert den Code auf Duplikate, die oft durch Copy & Paste enstehen, und unterstützt neben Visual C# und Visual Basic auch Sprachen wie Java, Phyton, Ruby oder ActionScript3.

Nitirq ist ein leistungsfähiges Tool für Code-Reviews, das Hilft die Codebasis zu verstehen, Typen und Methoden zu finden die refaktorisiert werden sollten, benutzerdefinierte Metriken zu erstellen und den Einsatz von Best Practices durchzusetzen.

Leider lassen sich die beiden Tools ab Windows 8 nicht mehr starten bzw. installieren. Sie werden seit Mitte 2012 auch nicht mehr weiter entwickelt und der Entwickler reagiert auch nicht auf E-Mails. Ich habe etwas experimentiert und es ist mir gelungen den Code, so gut es geht, wiederherzustellen. Den Sourcecode der beiden Projekte habe ich auf Bitbucket und GitHub zur Verfügung gestellt. Vielleicht hat jemand Interesse diese Tools im Rahmen eines OpenSource Projektes weiter zu entwickeln.

Atomic Sourcecode: Bitbucket | GitHub
Nitriq Sourcecode: Bitbucket | GitHub

Templates und Snippets für Visual Studio

Als Programmierer versucht man sich die täglich Arbeit zu erleichtern und wiederkehrende Abläufe zu automatisieren, wo es nur geht. Wieso immer eine Methode „zu Fuss“ schreiben, wenn man sie einfach mit einem Kurzbefehl einfügen kann? Oder warum immer eine Klasse anpassen, wenn eine Vorlage sie bereits so erstellen kann, wie man es möchte.

Für die Arbeit mit Visual Studio verwende ich auch eine Reihe selbst erstellter Templates und Snippets, die mir die Arbeit einfacher macher und Zeit sparen. Diese habe ich jetzt als OpenSource Projekt veröffentlicht. Das Repository steht bei Bitbucket und GitHub zur Verfügung.

BASS Audio Library

Durch die Mitarbeit an einem Projekt, bin ich auf die interessante und sehr umfangreiche Un4seen BASS Audio Library gestossen. In Kombination mit der BASS.NET Library als .NET Wrapper, lassen sich damit sehr einfach Audiofunktionalitäten, wie Wiedergabe, Aufzeichnung und Streaming realisieren. Der Umfang ist überwältigend und lässt keine Wünsche offen. Die Libraries lassen sich mit mono.NET sowie Xamarin verwenden, somit kann man Audio Projekte auch für OS X und Linux umsetzen.

Bug beim Parsen eines Währungsstring der tzm-CultureInfo in .NET

Beim Testen der Konvertierung numerischer Werte in einen Währungsstring und umgekehrt ist mir ein Fall aufgefallen, den man als Bug einstufen kann. Das Parsen von Währungsstrings, unter Verwendung der CultureInfo als FormatProvider, funktioniert bis auf die tzm-CultureInfo problemlos. Der Versuch einen mit der tzm-CultrueInfo formatierten Währungsstring zu parsen verursacht eine FormatException.

Ergebnis Meldung:    System.FormatException : Die Eingabezeichenfolge hat das falsche Format.
Ergebnis StackTrace:
bei System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
bei System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
bei System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider)
bei Currency.Test.CurrencyTest.TestCurrency(CultureInfo cultureInfo) in CurrencyTest.cs:Zeile 29.

Bei der tzm-CultureInfo ist der CurrencyDecimalSeparator = "." und der CurrencyGroupSeparator = ",". Tauscht man jedoch die Werte, wird der Währungsstring korrekt geparsed. Das Problem besteht in den .NET Framworks 2.0 bis 4.5.1. Eine Lösung für das Problem habe ich leider nicht gefunden. Die einzige Möglichkeit bei dynamischen Unit Tests besteht darin diese CultureInfos rauszufiltern.

Eine weitere Besonderheit ist mir auch beim Testen mit dem Framework 3.5 aufgefallen. Das Parsen eines Währungsstrings mit einer neutralen CultureInfo wird mit einer NotSupportedException quitiert. Andere Frameworkversionen sind davon nicht betroffen.

Ergebnis Meldung:    System.NotSupportedException : Die Kultur "af" ist neutral. Sie kann nicht als die aktuelle Threadkultur festgelegt werden, da sie nicht zum Formatieren und Analysieren verwendet werden kann.
Ergebnis StackTrace:
bei System.Globalization.CultureInfo.CheckNeutral(CultureInfo culture)
bei System.Globalization.CultureInfo.get_NumberFormat()
bei Currency.Test.CurrencyTest.TestCurrency(CultureInfo cultureInfo) in CurrencyTest.cs:Zeile 21.

Die tzm-CultureInfo steht für Tamazight, Berbersprachen und -dialekte. Nun wird man wohl selten in die Verlegenheit kommen diese CultureInfo direkt zu verwenden, aber im Hinblick auf dynamische Unit Tests ist es vorteilhaft von diesen Einschränkungen zu wissen.

Weiterlesen

Alternative Implementierungen der Factory

Neben dem Factory Method und Abstract Factory Entwurfsmuster gibt es zwei alternative Implementierungen der Factory. Es sind die Simple Factory (einfache Fabrik) und die Static Factory Method (statische Fabrikmethode). Diese Implementierungen sind keine Entwurfsmuster, sondern eher Programmieridiome. Dennoch ist es wichtig sie zu kennen und zu wissen wann ihr Einsatz sinnvoll ist.

Um die Implementierung zu erläutern, greifen wir das Beispiel der Pizzeria wieder auf, welches bereits bei den Factory Entwurfsmustern verwendet wurde.

Weiterlesen

Das Abstract Factory-Muster

Definition

Das Abstract Factory-Muster (Abstrakte Fabrik) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Erzeugungsmuster (Creational Design Pattern). Das Muster „bietet eine Schnittstelle zum Erstellen von Familien verwandter oder zusammenhängender Objekte an, ohne konkrete Klassen anzugeben“ (EvKbF S. 156).

Beschreibung

Das Abstract Factory-Muster ist mit dem Factory Method-Muster eng verwandt. Ebenso wie das Factory Method-Muster verwendet das Abstract Factory-Muster eine abstrakte Schnittstelle, um einen Satz verwandter Produkte zu erstellen, ohne die konkreten Produkte zu kennen. Das trägt ebenfalls zur Reduzierung der Abhängigkeiten, da der Client von den konkreten Produkten entkoppelt wird. Auch hier wird das folgende OO-Entwurfsprinzip angewendet:

„Stützen Sie sich auf Abstraktionen. Stützen Sie sich nicht auf konkrete Klassen.“
Das Abhängigkeits-Umkehrungs-Prinzip

Die Methoden in einer Abstrakten Fabrik, werden als Fabrikmethoden implementiert. Jede Methode ist dafür verantwortlich, ein konkretes Produkt zu erstellen. Dazu wird eine Unterklasse der Abstrakten Fabrik erstellt, in der die Implementierung der Methoden erfolgt, die ihrerseits die konkreten Produkte erzeugen. „Fabrikmethoden sind ein natürliches Mittel zur Implementierung von Produkt-Methoden in ihren abstrakten Fabriken.“ (EvKbF S. 158)

Weiterlesen

Das Factory Method-Muster

Definition

Das Factory Method-Muster (Fabrikmethode) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Erzeugungsmuster (Creational Design Pattern). Das Muster „definiert eine Schnittstelle zur Erstellung eines Objekts, lässt aber die Unterklassen entscheiden, welche Klassen instanziert werden. Factory Method ermöglicht einer Klasse, die Instanzierung in Unterklassen zu verlagern“ (EvKbF S. 134).

Beschreibung

Eines der wesentlichen Merkmale der objektorientierten Programmierung sind die Beziehungen bzw. Abhängigkeiten zwischen den Objekten. Ein Entwurf mit vielen Abhängigkeiten kann jedoch sehr schnell unflexibel und schwer wartbar werden. Eine vollständige Vermeidung von Abhängigkeiten ist nicht möglich. Das Ziel sollte daher sein die Abhängigkeiten in einem Entwurf auf ein Minimum zu reduzieren. Durch die Anwendung des folgenden OO-Entwurfsprinzips, ist das Factory Method-Muster eine Hilfe dieses Ziel zu erreichen:

„Stützen Sie sich auf Abstraktionen. Stützen Sie sich nicht auf konkrete Klassen.“
Das Abhängigkeits-Umkehrungs-Prinzip

Die Verwendung von Abstraktionen verleiht einem Entwurf Flexibilität. Neue Anforderungen lassen sich schnell integrieren, ohne dass der bestehende Code geändert werden muss. Welche Rolle das Factory Method-Muster dabei spielt, beschreibt das Buch „Entwurfsmuster von Kopf bis Fuß“ auf der Seite 125, wie folgt:

Eine Factory Method-Fabrikmethode kümmert sich um die Objekt-Erstellung und kapselt sie in einer Unterklasse. Damit wird der Client-Code in der Superklasse vom Objekt-Erstellungscode in der Unterklasse entkoppelt.

  • Eine Fabrikmethode kümmert sich um die Objekt-Erstellung und kapselt sie in einer Unterklasse. Das entkoppelt den Client-Code in der Superklasse von der Objekt-Erstellung in der Unterklasse.
  • Eine Fabrikmethode liefert ein Produkt zurück, das üblicherweise innerhalb der Methoden verwendet wird, die in der Superklasse definiert werden.
  • Eine Fabrikmethode isoliert den Client (den Code in der Superklasse) so, dass er nicht wissen muss, welche konkrete Art von Produkt tatsächlich erstellt wird.
  • Eine Fabrikmethode kann so parametrisiert sein (oder nicht), dass sie unter verschiedenen Formen eines Produkts auswählt.

Die Kapselung der Objekt-Erstellung in einer Klasse bietet die Möglichkeit, diese in verschiedenen Clients wiederzuverwenden. Gleichzeitig hat man auch nur eine einzige Stelle, an der man Änderungen durchführen muss, sollte sich die Implementierung ändern.

Weiterlesen

Das Decorator-Muster

Definition

Das Decorator-Muster (Dekorierer) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Strukturmuster (Structural Design Pattern). Das Muster „fügt einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu. Dekorierer bieten eine flexible Alternative zur Ableitung von Unterklassen zum Zweck der Erweiterung der Funktionalität“ (EvKbF S. 91).

Beschreibung

Die Vererbung ist eines der grundlegenden Konzepte in der objektorientierten Programmierung. Jedoch sind auch diesem Konzept Grenzen gesetzt und seine Verwendung führt „nicht immer zu den flexibelsten oder wartbarsten Entwürfen“ (EvKbF S. 85). Eine überstrapazierte Verwendung der Vererbung kann zur Entstehung vieler Klassen führen und den Entwurf schließlich unübersichtlich werden lassen. Um diese Probleme zu vermeiden, verwendet das Decorator-Muster, ähnlich dem Strategy-Muster, die Komposition und Delegation um Verhalten „zu vererben“. Dabei setzt es auf eines der OO-Entwurfsprinzipien:

„Klassen sollten für Erweiterung offen, aber für Veränderungen geschlossen sein.“
Das Offen/Geschlossen-Prinzip

Das Decorator-Muster ermöglicht es das Verhalten einer Klasse dynamisch zu ändern. Dabei wird eine Klasse (Komponente), dessen Verhalten man erweitern will, von einer anderen Klasse (Dekorierer) dekoriert oder „umhüllt“. (Im englischen bedeutet „umhüllen“ „to wrap“. Daher auch der bekannte Begriff „Wraper-Klassen“.) Der Dekorierer verwendet die selbe Schnittstelle wie das zu dekorierende Objekt, womit er ebenso anstelle des eigentlichen Objekts verwendet werden kann. Dabei werden die Methodenaufrufe an die Komponente weiter delegiert und das eigene Verhalten davor oder danach ausgeführt.

Diese Methodik ermöglicht es bestehende Objekte um neue Funktionalitäten zu erweitern, indem man neuen Code schreibt, anstatt den vorhanden Code zu ändern. Dadurch sinkt die Gefahr erheblich unbeabsichtigte Fehler oder Nebeneffekte zu verursachen. Ebenso erreicht man auch einen Entwurf der flexibel genug ist neue Funktionalitäten aufzunehmen und den geänderten Anforderungen gerecht zu werden.

Weiterlesen