Probleme beim Einloggen
Cornelia Oeffner Vorstellung
Liebe Gruppenmitglieder,
vielen Dank für die Aufnahme in die Gruppe.
Ich möchte die Gelegenheit nutzen und mich hier kurz vorstellen:
Mein Name ist Cornelia Oeffner. Ich bin Inhaberin eines jungen und wachsenden Unternehmens, welches sich auf die Direktsuche von Mitarbeitern spezialisiert hat. Wir bieten den klassischen „Executive Search“ mit Telefonident und Ansprache an.
Ich freue mich sehr auf mögliche geschäftliche Synergien und ein gelungenes Netzwerken.
Herzliche Grüße,
Cornelia Oeffner
Markus Wagner Clean Code Developer - Teil 1
Mehr als nur schön programmieren!
Markus Kraus Gradwechsel
CCD: "Sobald ein Entwickler [...] 21 Tage ohne Wechseln des Armbands gearbeitet hat, kann er den Grad als gemeistert ansehen, zum nächsten fortschreiten und dessen Armband überstreifen."
Das hat mich frustriert. Ich wäre nie aus dem Roten Grad heraus gekommen. An irgendeinem der 21 Tage habe entweder mal ISOP verletzt oder die Root Cause Analysis abgebrochen oder ... Nobody is perfect - ich jedenfalls nicht 21 Tage lang.
Jetzt wechsele ich unabhängig davon alle 3 Wochen in den nächsten Grad. Ich mache mir bei der täglichen Reflektion meine Verfehlungen bewusst, gelobe mir Besserung und habe wieder mehr Freude am CCD.
Markus Wagner Stefan Lieser
+2 weitere Kommentare
Letzter Kommentar:
Christian Schmoll
Oder, um es mit den Worten von Joshua Bloch zu sagen:
"Learning the art of programming, like most other disciplines, consists of first learning the rules and then learning when to break them."
Nur für XING Mitglieder sichtbar Law of Demeter + SLA
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Ralf Westphal
+2 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
Ja, das kann gut sein, dass tieferliegende Ungereimtheiten aufgedeckt werden. Deshalb sollte auch die Richtung offen sein, in die die Konversation wandert. Denn sonst hängt man sich an lokale Lösungen, die nur kurzfristig helfen.
Was bedeutet "Datenstrukturen immer nur über Schnittstelle verfügbar"? Irgendwoher kommt eine Datenstruktur natürlich, irgendwer baut sie. Das könnte im Rahmen der Beschaffung aus einer Datenbank geschehen.
Die wesentliche Frage ist für mich aber nicht, woher sie kommen, sondern was ihr Zweck ist.
Das ist für mich ganz klar: der Zweck von Datenstrukturen ist, Datenstruktur sein. Sie bringen Daten in eine gewisse Form, z.B. fassen sie Rechnungspositionen in einer Rechnung zusammen und hängen an die Rechnung auch noch einen Summenblock inkl. MwSt-Beträgen dran.
Eine solche Objekthierarchie:
Rechnung
Position*
MwStPosition*
*ist* Daten. Die Tiefe der Schachtelung ist dabei völlig beliebig, zb:
Verzeichnis
Datei*
Verzeichnis*
Als rekursive Datenstruktur ist kein Ende abzusehen :-)
Und was will man dann machen, wenn man darauf zugreift? Man greift über einen Pfad auf Daten zu:
rechnung.Positionen[0].Menge
rechnung.MwStPositionen[0].Betrag
verzeichnis.Verzeichnisse[0].Verzeichnisse[1].Verzeichnisse[2].Dateien[3].Name
Das ist die natürliche Form von Daten. Es ist ihr Auftrag, diese Form zu haben und zu publizieren. Da gibt es nichts zu kapseln oder zu verbergen.
Aber was hängen an Datenstrukturen für Funktionen? Was ist "Datenstruktur-Logik" Da scheiden sich die Geister.
Meine Meinung: So wenig wie möglich. Und dann auch konzentriert auf den Zweck, d.h. auf "das Strukturige".
Wenn der Auftrag lautet "Struktur einer bestimmten Form sein", dann kann es nur zwei Arten von Methoden auf Datenstrukturobjekten geben:
1. Methoden, die die Struktur aufbauen und ihre Konsistenz sicherstellen.
2. Methoden, die es erlauben, die Struktur zu traversieren.
Bei einer Rechnung könnte zur Konsistenz gehören, dass sie mit Logik sicherstellt, dass alle minimal notwendigen Daten vorhanden sind. Das könnte bedeuten, dass MwSt-Positionen virtuell sind und von der Datenstruktur berechnet werden. Wenn das sehr, sehr einfach möglich ist, ok. Wenn das jedoch ausartet... dann gehört es nicht in die Datenstruktur, sondern in eine Factory oder dergleichen.
"Ausarten" ist für mich immer der Fall, wenn Datenstrukturen über sich hinaus greifen müssen auf andere Objekte oder Frameworks. Anders formuliert: Logik in Datenstrukturen soll nur mit Objekten innerhalb der Datenstruktur arbeiten.
Bei einem Verzeichnisbaum könnte zur Traversierung gehören, dass ein Iterator angeboten wird, bei dem man wählen kann, ob die Knoten im Baum depth-first oder breadth-first vorgelegt werden.
foreach(var v in verzeichnis.Verzeichnisse_in_der_Tiefe)
...
Bei einem Stack als Datenstruktur gehört zum Thema Konsistenz, dass Push/Pop angeboten werden. Ein abstract data type (ADT), der zur Abstraktion über das hinaus, was die darin gekapselte "rohe" Datenstruktur bietet (z.B. eine Liste).
Ob eine Datenstruktur mit Feldern oder Properties (Getter/Setter) ausgestattet ist, finde ich unerheblich. Sie muss halt ihren Auftrag innerhalb eines Vertrauensmilieus erfüllen. Wenn das Vertrauen gering ist, dann eher Daten hinter Properties verbergen, damit niemand die Datenstruktur kaputtmachen kann. In vielen Fällen ist das aber nicht nötig.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 5.001
  • Sichtbarkeit: offen
  • Beiträge: 482
  • Kommentare: 2.983