In der Informationstherorie ist die kleinste mögliche Informationseinheit ein Bit! 0 oder 1, An oder Aus, Offen oder Zu, Wahr oder Falsch. Alles mögliche Darstellungsformen, genauergesagt Interpretationsformen dieser minimalen Informationseinheit. Eine funktionierende Klotür kann nur Offen oder Verschlossen sein. Aber es existieren mehrere Interpretationsmöglichkeiten, die sich auf diesen Zustand beziehen. Wenn ich aufs Klo möchte, interessiert mich natürlich ob eine Kabine Frei oder Besetzt ist, da ich natürlich eine dieser Kabinen verwenden möchte. Befinde ich mich bereits in einer Kabine, so interessiert mich nicht mehr ob diese Kabine frei ist, denn ich weiss ja das sie es nicht mehr ist, ich bin ja schliesslich drin. Aber mich interessiert nun, ob die Tür Verschlossen oder Offen ist. Ich möchte ja schliesslich meinen Geschäftigkeiten ungestört nachgehen. Somit haben wir mehrere Interpretationsmöglichkeiten des Türzustandes. Dieser ist von dem Zustand abhängig, ob ich mich vor oder hinter der Tür befinde.
Wenn wir die Brücke jetzt zur Softwareentwicklung schlagen, könnte man das Vor bzw. Hinter der Tür als “Ich verwende eine Komponente” bzw. als “Ich entwickle eine Komponente” verstehen. Der Komponentenentwickler wird sich sicherlich für den Zustand interessieren, das eine Kabine besetzt ist, denn dann muss er mit den ”Daten” irgendwas anstellen. Was kümmern ihn also die leeren Kabinen?
Jemand der diese Komponente jedoch verwendet, den interessiert nicht ob eine Kabine bereits besetzt ist. Ihn interessieren besetzte Kabinen nicht wirklich. Jemand der schon einmal enorm dringend aufs Klo musste, wird das nachvollziehen können. Uns interessieren in diesem Moment nicht die 15 Kabinen die Besetzt sind, uns interessiert genau die Kabine die in dem Moment frei ist.
Dies ist der Grund, warum wir in diesem Fall an der Komponenten-Schnittstelle kein Flag zur Verfügung stellen sollten, welches Kabine.IstBesetzt heisst. Dieses Flag sollte stattdessen Kabine.IstFrei heissen. Denn das interessiert den Anwender an dieser Komponente.
Der Komponentenentwickler sollte aber Intern mit dem Zustand arbeiten, den er am Häufigsten braucht (was hier der Zustand Kabine.IstBesetzt sein dürfte). Wie lösen wir dieses Dilemma? Ganz einfach, das Zauberwort heisst Kapselung. Nehmen wir als Beispiel einmal C# als Zielsprache. Dort können wir mit dem IstBesetzt intern arbeiten, bieten aber ein Property IstFrei an der Schnittstelle an:
Somit arbeitet jeder mit der Interpretation, die für ihn am Besten geeignet ist!
Diese Betrachtungsweise ist natürlich nicht nur auf Flags beschränkt! Dies gilt für alle Daten, Methoden und Properties die eine Schnittstelle nach außen offenlegt.
“Dies gilt für alle Daten, Methoden und Properties die eine Schnittstelle nach außen offenlegt.”
Naja, nehmen wir mal komplexere Methoden. Sagen wir mal eine Methode die die Kosten einer Firma berechnet “GetCosts()” da reicht es nicht einfach das resultat zu negieren um die Umsätze zu ermitteln. ;)
Wollt ich nur mal angemerkt haben.
#lach# Das ist wohl Richtig…
Aber Deine Komponente wird sicherlich die Kosten feingranularer behandeln bzw. berechnen müssen. Zum Beispiel Posten die auf 3 Jahre abgeschrieben werden müssen/können oder auf 5 Jahre. Personalkosten, Gebäudekosten etc. Du könntest jetzt alles nach aussen geben (falls es gewünscht ist, musst Du das auch) und es dem Verwender der Komponente das aufzummieren der einzelnen Posten überlassen oder aber es in GetCosts() zusammenfassen :)
Aber: Das es für alles anzuwenden ist, war eher auf die Namensgebung in derart gerichtet, das sich die Namen an den Anwender der Komponente richten sollen. Nicht nach der inneren Arbeitsweise.