Einheiten und Schnittstellen

Aufgrund der Objektorientierung beschreibt man als Entwickler seine zu bearbeitenden Daten in Objekte. Logisch. Das sieht dann so aus:

public List<Product> GetProducts()

Doch was ist mit grundlegenden Einheiten? Für das Datum gibts im Framework ja das DateTime Objekt, aber was ist mit all den anderen Einheiten: Liter, Meter, Gigabyte usw. ? Die einfachste Antwort der Entwickler ist: Naja, das sind ja meist ganze Zahlen, also nehme ich ein Integer.
Eine Schnittstelle sieht dann so aus:

public void SetMailboxSize(int mailboxSize)

Das ist natürlich sehr unglücklich und wirft sofort die Frage auf: Was muss ich jetzt da rein geben? Die Antwort des Kollegen sieht dann (oft) so aus:

public void SetMailboxSize(int sizeInKilobyte)

Ok, jetzt wissen wir was da rein muss alles klar. In meinem Fall hatte das so lange funktioniert bis wir feststellten, dass ich in Kibibit (also zur Basis 2) und er in Kilobit (zur Basis 10) gerechnet hatte, was natürlich zu suboptimalen Ergebnissen führt. Das gemeine ist das dieser Fehler erst bei großen Datenmengen auffällt da der Unterschied beim 1 Gigabyte ja nur 24 Megabyte beträgt.

Ein weiteres Problem ist, dass man dieser Methode auch eine falsche Einheit übergeben kann. So könnte ein Entwickler einfach eine 1 übergeben, weil der Nutzer auf der Oberfläche ja auch 1 Gigabyte ausgewählt hat. Das Problem ist das ein Integer keine Aussagekraft über die Einheit hat und sie deshalb auch nicht validiert werden kann. Tja, und alles was schief gehen kann, geht auch irgendwann schief…

Deshalb ist es besser sich für alle Einheiten die man braucht auch eine Klasse anzulegen.

public void SetMailboxSize(DataSize mailboxSize)

Das hat nicht nur den Vorteil, dass man keine falschen Einheiten übergeben kann, sondern auch das man sämtlichen Code zum Umrechnen und Konvertieren der Einheit an einer Stelle hat.

Hier ein Beispiel wie so eine DataSize Klasse aussehen kann:

 

  /// <summary>
    /// Stores information about the size of data. The base unit is Byte, multiples are expressed in powers of 2.
    /// </summary>
    class DataSize
    {
        public enum Unit
        {
            Kilo = 1,
            Mega = 2,
            Giga = 3,
            Terra = 4,
            Peta = 5,
            Yotta = 6
        }
        public DataSize()
        { }
        /// <summary>
        /// Create a new DataSize Object
        /// </summary>
        /// <param name="bytes">number of bytes</param>
        public DataSize(UInt64 bytes)
        {
            Bytes = bytes;
        }

        /// <summary>
        /// Size of the data in Bytes
        /// </summary>
        public UInt64 Bytes { get; set; }

        /// <summary>
        /// converts the current value into
        /// </summary>
        /// <param name="unit"></param>
        /// <returns></returns>
        public Decimal ConvertTo(Unit unit)
        {
            return Decimal.Divide(Bytes, (Decimal)Math.Pow(1024 ,(int)unit));
        }

        /// <summary>
        /// Loads an amount of bytes
        /// </summary>
        /// <param name="unit">unit to load</param>
        /// <param name="value">bytes to load</param>
        public void GetFrom(Unit unit, Decimal value )
        {
            Bytes = Decimal.ToUInt64(value * (Decimal)Math.Pow(1024, (int)unit));
        }
    }

Die Information wird intern in einer Basiseinheit, in diesem Fall Byte gespeichert und bei Bedarf umgerechnet. Das Ganze kann man natürlich für alle möglichen Einheiten tun und wesentlich erweitern. Wichtig ist nur, dass reale Einheiten auch einen eigenen Datentypen bekommen der klar macht um was es sich handelt.

About the author

4 Responses

1. 

   Norbert

   24. October 2012

   Der DateTime-Typ ist als struct abgebildet und genau das wäre eine Verbesserung der gezeigten Lösung. GetFrom impliziert auch etwas anderes. Hier sollte nicht der innere Wert verändert werden, warum nicht eine neue Instanz zurückliefen, wie das auch DateTime macht?

   Reply
2. 

   Oliver Guhr

   26. October 2012

   Vielen Dank für dein Kommentar. Das war mir noch nie so richtig klar, worin besteht der Vorteile einer Struct gegenüber einer Klasse? Also ich kenne die Struct als “leichtgewichtige” Klasse. Macht sich das dann im Speicherverbrauch bemerkbar oder hat das andere Gründe?
   Mit dem Namen war ich auch noch nicht ganz zu frieden, das werde ich nochmal anpassen.

   Reply
3. 

   Norbert

   29. October 2012

   Struct = Wertetyp; Class = Referenztyp. Schau mal hier: http://msdn.microsoft.com/de-de/library/saxz13w4(v=vs.110).aspx

   Reply
4. 

   Carsten

   8. March 2013

   Norbert meint, glaub ich, nicht nur struct sondern auch, dass der Typ unveränderbar sein sollte.

   Reply