Kategorie: Softwareentwicklung

Datenfelder in C# und PHP 👍 👎

Da ich regelmäßig – insbesondere von PHP-Entwicklern – gefragt werde, wie sich das dort allseits beliebte Array in C# verwenden lässt, möchte ich dazu eine kleine Gegenüberstellung präsentieren.

Zuerst einmal sollte festgestellt werden, dass Arrays unter PHP sehr vielseitig eingesetzt werden, wofür andere Programmiersprachen (wie beispielsweise C#) jeweils eigens optimierte Datenstrukturen vorsehen. Nicht zu vergessen ist natürlich ganz allgemein die unter C# strengere Typisierung.

Wir beginnen die Beispiele demnach also erst einmal mit einfachen Listen und gehen schließlich auch auf mehrdimensionale und assoziative Felder ein.
Liste von Zeichenketten: PHP
010203
$data = ["Ab", "Cd", "Ef"];
$data[] = "Yz";
Liste von Zeichenketten: C# (nativ)
01
string[] data = {"Ab", "Cd", "Ef"};
Es gibt jedoch noch eine elegantere Lösung: Generische Container. Hierbei handelt es sich um vom konkreten Datentyp abstrahierte Mechanismen zur Sammlung und Verwaltung von Daten. Sehen wir uns also das o. g. Beispiel mit Hilfe der generischen List-Klasse in C# an:
Liste von Zeichenketten: C# (generisch)
010203
List<string> data = new List<string>() {"Ab", "Cd", "Ef"};
data.Add("Yz");
Durch den Aufruf entsprechender Instanzmethoden können wir dadurch sehr komfortabel neue Daten hinzufügen, den Inhalt sortieren und natürlich auch per LINQ darauf operieren. Dank Implementierung eines sog. Indexers ist im Übrigen auch bei dieser Variante der gewohnte null-basierte Zugriff per Index z. B. per data[0] möglich.

Gehen wir nun also einen Schritt weiter und stellen mehrdimensionale Felder gegenüber:
Mehrdimensionales Feld: PHP
010203040506
$data = [    ["Ab", "Cd"],    ["Ef", "Gh"]];
$data[] = ["Wx", "Yz"];
Mehrdimensionales Feld: C# (nativ)
01020304
string[,] data = {    {"Ab", "Cd"},    {"Ef", "Gh"}};
Mehrdimensionales Feld: C# (generisch)
010203040506
List<List<string>> data = new List<List<string>>() {    new List<string>() {"Ab", "Cd"},    new List<string>() {"Ef", "Gh"}};
data.Add(new List<string> {"Wx", "Yz"});
Zum Schluss sollen natürlich noch assoziative Felder erwähnt werden, welche wir in C# mit Hilfe eines Dictionary umsetzen:
Assoziatives Feld: PHP
010203040506
$data = [    'FirstName' => "Holger",    'LastName' => "Stehle"];
$data['City'] = "Berlin";
Assoziatives Feld: C#
0102030405060708
Dictionary<string,string> data = new Dictionary<string,string>() {    {"FirstName", "Holger"},    {"LastName", "Stehle"}};
data.Add("City", "Berlin"); // – oder auch -data["City"] = "Berlin";
Zum Durchlaufen eines solchen Feldes in C# bietet sich die Verwendung der KeyValuePair-Struktur an:
Assoziatives Feld durchlaufen: C#
01020304
foreach(KeyValuePair<string,string> entry in data) {    // entry.Key: "FirstName", "LastName" und "City"    // entry.Value: "Holger", "Stehle" und "Berlin"}
Das soll es für den Moment auch erst einmal gewesen sein, zukünftig möchte ich jedoch noch ein paar derartiger Gegenüberstellungen durchführen. Insbesondere auch auf die generische Entwicklung unter C# werde ich noch gesondert in weiteren Beiträgen eingehen.

Schnittstellenbeschreibungen 👍 👎

Vor Kurzem war ich damit beschäftigt, die Schnittstellen zweier externer Anbieter zu implementieren. Es handelte sich um eine REST- und eine SOAP-basierte Schnittstelle ähnlichen Umfangs, die per PHP angesprochen werden sollte. Dabei fielen mir jedoch erhebliche qualitative Unterschiede der Schnittstellenbeschreibungen auf.

Die REST-basierte Schnittstelle wurde wohl eher von der Marketing-Abteilung zur Bewerbung des Produktes geschrieben, als von Entwicklern für Entwickler. Nicht nur die technische Inkonsistenz, sondern vor allem auch der Schreibstil waren mehr verwirrend als hilfreich. Nicht zuletzt fehlten einige wesentliche Informationen zur Verwendung (u. a. Wertebereiche), die sich schließlich erst durch einige Versuche ergaben, die in diesem Fall zu allem Überfluss auch noch jeweils kostenpflichtig waren. Der relevante Abschnitt des Dokumentes belief sich auf etwa 25 Seiten, die man sich aber auch erst einmal zusammensuchen musste. Fehlermeldungen und Hinweise hätten an der ein oder anderen Stelle ebenfalls nicht geschadet.

Auf der anderen Seite war die Beschreibung der SOAP-Schnittstelle des anderen Dienstes mit unter 10 Seiten knapp gehalten. Die zur Verfügung stehenden Methoden und deren Parameter wurden ohne große Umschweife erwähnt und mit allen notwendigen Informationen beschrieben. So ergab es sich, dass der eigentlich als schnell implementierbar gedachte erste Dienst auf REST-Basis etwa 3-4 mal so lange zur Umsetzung bedurfte, als der als umfangreicher eingeschätzte SOAP-Dienst.

Insofern möchte ich gerne Anbieter von Webdiensten, die das hier evtl. lesen, dazu ermuntern, ihre Schnittstellenbeschreibung vor der offiziellen Veröffentlichung mit einem externen Entwickler im Rahmen einer vollständigen Implementierung durchzugehen, um derartige Schwachstellen schnell aufdecken zu können. Insbesondere sollte es auch immer eine Testumgebung geben, die sich nach Außen wie die eigentliche Schnittstelle verhält, jedoch keine Auswirkungen (insbesondere keine Kosten) verursacht.

Magische Zahlen 👍 👎

Immer wieder sehe ich in diversen Projekten Zahlen im Quelltext, die sich nicht ohne Weiteres zuordnen lassen und nicht selten sogar einer Erklärung des Entwicklers bedürfen. Dies ist üblicherweise schlechter Programmierstil.

Es ist immer besser, derartige Zahlen – je nach Unterstützung der verwendeten Programmiersprache – als Enumeration oder Konstanten einer Klasse mit sprechendem Namen abzulegen. Dies hat neben der verbesserten Verständlichkeit auch den Vorteil, dass Änderungen am Wert ggf. zentral durchgeführt werden können.

Nebenbei bemerkt wird die Begrifflichkeit "magische Zahl" in der Informatik auch als Bezeichnung für spezielle Werte zur Kennzeichnung von Dateiformaten verwendet.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche