' schrieb:... Ebenen parameterunabhängiger zu gestalten bedeuetet doch auch immer einen gewissen Mehraufwand respektive (
) eine komplexere Struktur.
Mehraufwand ja, komplexere Struktur auf keinen Fall.
Eine Kapselung führt immer zu einer einfacheren Struktur. Der Mehraufwand resultiert daher, weil man nicht direkt auf einen Parameter außerhalb der eigenen Ebene (Klasse, Modul, etc) zugreifen soll. Was gänge, wäre der Parameter als z.B Globale Variable typisiert. Man soll also in der anderen Ebene (Klasse, Modul etc.) ein Property schaffen, um dann auf dem Umweg über den Property-Aufruf an den Parameter zu kommen. (Mit Property hat die Klasse die Möglichkeit zu Zugriff zu verweigern, was nicht geht, wenn der Parameter in einer GV liegt). Ein "Property" in einer "FGV" ist der Enum-Eingang in Verbindung mit einem (leider) Variant Ein-/Ausgang.
Zitat:Hier z.B.: Normale Schleife gegen Timed-Loop mit Erzeuger Verbraucher Struktur. Wenn man also mit den Nachteilen der parameterabhängigereren Struktur leben kann, oder sogar gut Leben kann, oder sogar Vorteile darin sieht, ist das Prinzip der Kapselung zu hinterfragen respektive nicht pauschal als vorteilhaft anzusehen.
Hinterfragt werden kann das Prinzip der Kapselung nicht. Und es ist auch per se immer besser.
Das Problem ist halt immer die Verhältnismäßigkeit. Wenn, wollte ich der Kapselung gerecht werden, wenn ich also extremen Aufwand treiben muss, nur um ein Feature für 5Cent zu realisieren, wird keiner (und ich schon gar nicht) Einwände haben. Irgendwann kann ich nämlich absehen, dass die Nicht-Einhaltung der Kapselung in diesem einen Falle eigentlich gar nichts ausmacht. Was aber nichts daran ändert, dass es nach Lehrbuch falsch ist.
Und wenn ich hier einen (virtuellen) Vortrag halte, dann muss ich mich immer zuerst an die Lehrbuchmeinung halten. Zumindest dann, wenn einer ganz allgemeine Fragen hat. Danach kommen erst die durch die Praxis gegeben Einschränkungen.