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

Mac Startsound de- und aktivieren

In den Einstellungen von OS X gibt es leider keine Möglichkeit den Startsound eines Mac zu deaktivieren. Das kann man aber mit einem einfachen Befehl über das Terminal lösen.

sudo nvram SystemAudioVolume=%00

Mit dem folgenden Befehl lässt sich der Startsound wieder aktivieren.

sudo nvram -d SystemAudioVolume

GitHub Markdown Tipp

Auf GitHub kann man die Readme-Dateien bekanntlich in Markdown verfassen. Da ich mich noch mit Markdown vertraut mache, hatte ich so meine Anlaufschwierigkeiten.

Vor das erste Problem stellte mich ein einfacher Zeilenumbruch. Ein einfaches return oder ein \n brachten leider nicht das gewünschte Ergebnis. Nach etwas Suchen bin ich dann schließlich fündig geworden. In Markdown erzeugen zwei oder mehr Leerzeichen am Ende einer Zeile einen Zeilenumbruch.

Das zweite Problem war die Darstellung des #-Zeichens am Ende einea Markdown-Headers. In Markdown wird ein Header mit dem #-Zeichen eingeführt. Endet der Satz ebenfalls mit einem #-Zeichen (z.B. Examples in C#), wird es nicht angezeigt. Abhilfe schafft auch hier ein Leerzeichen am Ende der Zeile und der Satz wird korrekt angezeigt.

Writing Code Is Life

Writing Code Is Life – Programmieren heißt Leben

Dieses Zitat stammt von Marlin Eller, einen ehemaligen Entwickler bei Microsoft. Mit diesem einfachen Satz fasst er meine Faszination für das Programmieren zusammen. Für mich ist es eine Kunst, das Optimum herauszuholen, mit einem Minimum das Maximum zu erreichen. Deshalb liebe ich es neue Programmiersprachen, Konzepte und Ansätze zu lernen und diese bei der täglichen Arbeit einzusetzen.

Hier ein Auszug aus der Dokumentation “Leben nach Microsoft”, der die Faszination Programmieren sehr gut zusammenfasst.

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

Das Observer-Muster

Definition

Das Observer-Muster (Beobachter) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Verhaltensmuster (Behavioral Design Pattern). Das Muster “definiert eine Eins-zu-viele-Abhängigkeit zwischen Objekten in der Art, dass alle abhängigen Objekte benachrichtigt werden, wenn sich der Zustand des einen Objekts ändert” (EvKbF S. 51).

Beschreibung

Die Interaktion der Objekte ist ein essentieller Bestandteil der objektorientierten Programmierung. Fälle, in denen bestimmte Objekte über Veränderungen in anderen Objekten informiert werden müssen, sind recht häufig. Das Ziel sollte daher ein Entwurf sein, in dem so viel wie möglich entkoppelt ist und die Abhängigkeiten reduziert sind. Das Observer-Muster setzt auf ein OO-Entwurfsprinzip, das uns hilft dieses Ziel zu erreichen:

“Streben Sie für Objekte, die interagieren, nach Entwürfen mit lockerer Bindung.”

Die bekannteste Implementierung des Observer-Musters sind die Event Handler. Die Event Handler zeichnen sich durch eine einheitliche Schnittstelle aus, durch die der Entwurf flexibel bleibt. Um jedoch ein besseres Verständnis des Observer-Musters zu erhalten, wollen wir uns an einem Beispiel anschauen, wie man das Observer-Muster selbst implementieren kann.

Weiterlesen