Trait oder Elternklasse in einer Klassen Gruppe?

[MB]

moin,

Ich habe eine Klassengruppe, die, per Instanziierung, einen SQL Teilstring erzeugen. Ich nenne z.B. In, Between, Cases, Arithmetic, LogicContainer aus der Klassengruppe.

Die Klassen sind lose gekoppelt. Einige Klassen können sich gegenseitig, per Consrtructor Injection, aufrufen:

new LogicContainer(
  new Between(
    /* Params */,
    LogicConstant::_AND )
)

Jeder Klasse bekommt, per Constructor Injection mit dazugehörigem Interface (z.B. ExpressionInterface, PredicateInterface, FunctionInterface), Übergabewerte, die sie dann zwischenspeichen und ergänzen $this->addString( $expression->getString() ), um dann diese Zwischengespeicherten Werte, per Constructor Injection, an den nächsten weiter zureichen.

Alle Klassen müssen über die selben Methoden verfügen:

protected function addString ( string $string ) : void;

public function getString () : string;

Kann man dieses Klassen Gebildes mit Traits oder mit einer Elternklasse realisieren? Ich sehe da Pros & Cons: Hab ihr erfahrungen?

Ich für meinen Teil habs' mit einer abstrakten Elternklasse realisiert, von der alle Klassen erben und dann die Elternklasse mit Traits versehen. So spart man sich gehörig schreibarbeit.

lgmb

[pl]

Wenn Du beim Programmieren erfolgreich sein willst, musst Du Deinen eigenen Stil finden. Irgendwelche Entwurfsmuster nachzubauen bringt da gar nichts.

Schönen Tag.

[Gunnar Bittersmann]

@@pl

Wenn Du beim Programmieren erfolgreich sein willst, musst Du Deinen eigenen Stil finden. Irgendwelche Entwurfsmuster nachzubauen bringt da gar nichts.

Am besten unterscheidet sich der eigene Stil deutlich von dem, was alle anderen machen, damit er auch als eigener Stil erkennbar ist.

Von Hotti lernen heißt programmieren lernen.

</sarcasm>

LLAP 🖖

[pl]

@Gunnar Bittersmann

Deine Antwort ist nicht nur arrogant, sie geht auch am Thema vollständig vorbei. Programmieren ist ein Handwerk, das muss man selber lernen. Und das heißt, was man selber lernen muss, kann man gar nicht von jemand Anderem lernen.

Meine Erfahrung im Programmieren jedoch, die gebe ich hier gerne weiter. Auch wenn ich die Tatigkeit Programmieren nur noch zu therapeutischen Zwecken betreibe oder auch gerade deswegen: Da bekommt der Begriff "erfolgreich" nämlich eine ganz besondere Bedeutung.

Lass Dir das mal durch den Kopf gehen!

[Tabellenkalk]

Hallo,

was man selber lernen muss, kann man gar nicht von jemand Anderem lernen.

Das ist natürlich Quatsch.

Gruß
Kalk

[Christian Kruse]

Hallo pl,

Programmieren ist ein Handwerk, das muss man selber lernen.

Unser gesamtes Ausbildungssystem, sowohl im Handwerk als auch im Schulsystem, basiert darauf, dass andere etwas von einem Erfahreneren lernen. Entweder liegt die ganze Welt falsch oder du redest Stuss. Lass Dir das mal durch den Kopf gehen! 😉

Freundliche Grüße,
Christian Kruse

[Rolf B]

Hallo Christian,

Unser gesamtes Ausbildungssystem...

das Verhalten aller sozialen Lebewesen dieses Planeten...

Was ich nicht von anderen lerne, muss mir angeboren sein (=Instinkt). Die meisten menschlichen Verhaltensweisen gehören nicht dazu. Insbesondere nicht das Sitzen vor einem rechteckigen Leuchtdings, das Herumklopfen auf gut 100 kleinen Knöpfchen und das Herumschubsen eines kleinen Handschmeichlers. Also gut, so wie beschrieben könnte dieses Verhalten auch ein Schimpanse oder ein Murmeltier zeigen. Aber dabei kommt dann kein Perl-Script heraus. Höchstens nach einer Million Jahren ein Blatt mit der Aufschrift "To Be Or Not To Be", oder auch nur "This page intentionally left blank".

Rolf

[Der Martin]

Hallo,

Unser gesamtes Ausbildungssystem...

das Verhalten aller sozialen Lebewesen dieses Planeten...

Was ich nicht von anderen lerne, muss mir angeboren sein (=Instinkt).

es gibt noch eine dritte Möglichkeit: Den Weg zu einem bestimmten Ziel durch Ausprobieren finden. Ich vermute, vor allem mit dieser Methode haben unsere Vorfahren vor Jahrtausenden gelernt, welche Pflanzen (und welche Teile davon) man gefahrlos essen kann - und wie man sie eventuell vorbehandeln muss (rösten, wässern, ein halbes Jahr vergraben, mit etwas anderem mischen).

Diese Trial&Error-Methode kann man natürlich wieder mit Lernen von anderen (oder Lehren von anderen) kombinieren. Dann wird's effizient.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Diese Trial&Error-Methode kann man natürlich wieder mit Lernen von anderen (oder Lehren von anderen) kombinieren. Dann wird's effizient.

Oder genügend Blech hinstellen. Dann wird’s KI.

LLAP 🖖

[Felix Riesterer]

Lieber pl,

Deine Antwort ist nicht nur arrogant, sie geht auch am Thema vollständig vorbei.

das hast Du so provoziert.

Meine Erfahrung im Programmieren jedoch, die gebe ich hier gerne weiter. Auch wenn ich die Tatigkeit Programmieren nur noch zu therapeutischen Zwecken betreibe oder auch gerade deswegen: Da bekommt der Begriff "erfolgreich" nämlich eine ganz besondere Bedeutung.

Das bedeutet im Umkehrschluss, dass Deine Erfahrung im Programmieren für die hier Hilfesuchenden eher einen therapeutischen Wert hat, anstatt zielführende Wege zum Lösen ihrer Programmierprobleme zu bieten.

Lass Dir das mal durch den Kopf gehen!

Habe ich. Jetzt bist Du dran.

Liebe Grüße

Felix Riesterer

[Tabellenkalk]

Hallo,

Wenn Du beim Programmieren erfolgreich sein willst, musst Du Deinen eigenen Stil finden.

Dann kannste es aber haken, dich bei Unternehmen als Programmierer zu bewerben. Wenn die sich einen Beispielcode von dir schicken lassen, ist kreativer eigener Stil eher nicht so angesagt...

Gruß
Kalk

[Felix Riesterer]

Lieber pl,

Wenn Du beim Programmieren erfolgreich sein willst, musst Du Deinen eigenen Stil finden. Irgendwelche Entwurfsmuster nachzubauen bringt da gar nichts.

"nachbauen" klingt nach "nachmachen" oder "nachempfinden" bzw. "nachvollziehen". Das ist der Inbegriff des Lernens. Dein Einwand "bringt da gar nichts" ist also inhaltlich völlig wertlos.

Liebe Grüße

Felix Riesterer

[MB]

moin,

Wenn Du beim Programmieren erfolgreich sein willst, musst Du Deinen eigenen Stil finden. Irgendwelche Entwurfsmuster nachzubauen bringt da gar nichts.

Da muss ich den übrigen Kommentatoren recht geben bezogen auf deine Argumentation. Wozu haben wir den Schulen? Und nix anderes is es hier.

Natürlich spielen zusätzlich "autodidaktisches Lernen" und "Lerning by doing" auch eine sehr wichtige Rolle. Aber ohne Vorkenntnis des Theroretischen Wissens brings relativ wenig.

Und es ist extrem wichtig das man sich eine generelle Konvention erarbeitet, damit Programmiere besser kommunizieren können - musste ich am eigenen Leibe erfahren, da der Code den ich Refactorieren musste, extrem unsauber war und der, der den Code geschrieben hatte, sich keiner Schuld bewusst war. Insofern ist der Eigene Stil Gift für andere Programmierer 😕. Das ist meine Erfahrung und ich denke, die Kommentatoren Teilen meine Erfahrungen.

Es sei den Ich hab dich Falsch verstanden oder du hast was anderes gemein als du ausgedrückt hast 😉. Geht mir exakt genauso 😀.

Aber zurück zum Thread…

lgmb

[pl]

da der Code den ich Refactorieren musste, extrem unsauber war

Das ist Dein Ansatz auch. Genauer gesagt, Dein Ansatz ist viel zu kompliziert, Du erstickst Dich selbst in einer Klassenflut. Von daher wäre das Erste was zu tun ist, den Code zu vereinfachen.

Natürlich kann man Daten per Instanz einer fremden Klasse in seinen eignen Konstruktor hineinreichen, aber es geht auch anders. D.h., die Daten die Dein Konstruktor benötigt müssen ja keine Instanzen fremder Klassen sein.

Etwas weiter ausgeholt: Ein Framework ist abstrakt gesehen nichts weiter als ein Inferface! Denn Du hast Methoden die gleichnamig stets in derselben Reihenfolge aufgerufen werden. Also ist es naheliegend, daß diese Methoden nacheinander von einundderselben Instanz aufgerufen werden. Und diese FW-Instanz bekommt Daten entweder über den Konstruktor oder später.

Genauso wie die FW-Instanz auch Instanzen fremder Klassen bekommt, entweder bei der Instanzerstellung oder im Verlauf des Programms.

MFG

[MB]

moin,

da der Code den ich Refactorieren musste, extrem unsauber war

Das ist Dein Ansatz auch. Genauer gesagt, Dein Ansatz ist viel zu kompliziert, Du erstickst Dich selbst in einer Klassenflut.

wenn man einfache klassengebundene SELECT-Befehle machen will ja, gebe ich dir Recht. Wenn du aber eine sehr komplexe SQL Abfrage hast, mit Subselects usw. braucht man eine Struktur von Klassen die dann verschachtelt den SQL string stück für stück zusammen bauen, dann auf Type, Sequenz, Wohlgeformtheit, usw. validieren und ab dafür. Je weniger Fehler mir passieren können desto besser, und wenn fehler passieren, meckert mein SQL Builder System per [Type]Exception was ich doch falsch gemacht haben könnte.

Natürlich kann man Daten per Instanz einer fremden Klasse in seinen eignen Konstruktor hineinreichen, aber es geht auch anders. D.h., die Daten die Dein Konstruktor benötigt müssen ja keine Instanzen fremder Klassen sein.

Neben bei: Ich hasse Array's flut. Meiner Erfahrung nach sind Array's sehr unspezifisch und ich mag sie garnicht! Man muss wissen, welche struktur das Array hat, welchen Datentyp ein Feld hat, obs Key-Value-Paare sind, usw. Mit einer ConstructorInjection hat man das Problem nicht.

lgmb

[Felix Riesterer]

Lieber MB,

Ich hasse Array's flut.

wozu der Apostroph?

Liebe Grüße

Felix Riesterer

[MB]

moin,

Ich hasse Array's flut.

wozu der Apostroph?

• Fachliche Bezeichnung (z.B. Keyword) wird bei mir in englisch fachsprachich in der Einzahl hervorgehoben geschrieben. Rein zur Orientierung im Text und in der Fachlichen Bezeichnung (z.B. Array und nicht Feld zum Flügen, -einer Tabelle oder -eines Schachbretts)
• Wenn ich mehrere Fachlichen Gegestände bennenen will und sich der in der Mehrzahl Fachterminus ändert hänge ich zur der Einzahl ein "s" dran ohne es hervorzuheben.
• Problem ist das sich Kramdown ander formatier wenn ich _Array_s hintippe. Also schreibe ich Array's, Array(s) oder Array s.
• Natürlich könnte ich auch Arrays aber mir ist unwohl dabei. Ich hoffe du verstehst es.

lgmb

[Tabellenkalk]

Hallo,

• Natürlich könnte ich auch Arrays aber mir ist unwohl dabei.

Unwohlsein ist in diesem Fall fehl am Platz. „Arrays“ ist hier korrekt.

Gruß
Kalk

[MB]

moin,

Nur ein exemplarisches Beispiel. Meinetwegen ein schlechtes beispiel

lgmb

[Der Martin]

Hallo,

Ich hasse Array's flut.

wozu der Apostroph?

• Wenn ich mehrere Fachlichen Gegestände bennenen will und sich der in der Mehrzahl Fachterminus ändert hänge ich zur der Einzahl ein "s" dran ohne es hervorzuheben.

okay, das wäre richtig. Naja, nicht immer: Vor allem bei Fachbegriffen aus dem Lateinischen weicht der Plural oft vom einfachen Anhängen eines s ab, z.B. Index, Indices (wobei die Pluralform Indexe auch gelegentlich vorkommt).

• Problem ist das sich Kramdown ander formatier wenn ich _Array_s hintippe. Also schreibe ich Array's, Array(s) oder Array s.
• Natürlich könnte ich auch Arrays aber mir ist unwohl dabei. Ich hoffe du verstehst es.

Nein. Nimm einfach den Stern anstatt des Unterstrichs, dann klappt der Wechsel auch mitten im Wort.

Ciao,
 Martin

[MB]

moin,

[...] Naja, nicht immer: Vor allem bei Fachbegriffen aus dem Lateinischen weicht der Plural oft vom einfachen Anhängen eines s ab, z.B. Index, Indices (wobei die Pluralform Indexe auch gelegentlich vorkommt).

Wir sind hier nicht im Lateinunterricht ;-). Um dein beispiel auf zu greifen würde ich sowas schreiben: Index's

lgmb

[Tabellenkalk]

Hallo,

Um dein beispiel auf zu greifen würde ich sowas schreiben: Index's

Und damit bescherst du einer Reihe von Lesern Unwohlsein. Möchtest du das?

Gruß
Kalk

[MB]

moin,

Hallo,

Um dein beispiel auf zu greifen würde ich sowas schreiben: Index's

Und damit bescherst du einer Reihe von Lesern Unwohlsein. Möchtest du das?

Sorry, an alle Lateiner. Ich drück mich nun mal so aus und kann es nicht besser. Ich selbst orientiere mich an diesen von mir definierten hervorgehobenen Markern. Und ich hoffe sehr, das diejenigen die meinen Thread lesen, den Sachverhalt besser verstehen können eben durch diese Textauszeichnungen. Mir jedenfalls geht es so. Unter anderem dafür habe ich die Auszeichnung ja vorgenommen. Ich hoffe du verstehst mein Anliegen für das Forum

lgmb

[Der Martin]

Guten Abend,

Um dein beispiel auf zu greifen würde ich sowas schreiben: Index's

Und damit bescherst du einer Reihe von Lesern Unwohlsein. Möchtest du das?

Sorry, an alle Lateiner.

nur um das nochmal klarzustellen: Es geht gar nicht primär um Latein, sondern um Deutsch. Das Wort Index existiert im Deutschen als Fremdwort (Lehnwort) aus dem Lateinischen, soweit okay. Nun ist das Wort aber noch nicht so weit eingedeutscht, dass es auch eine deutsche Pluralform gibt. Also benutzt man ersatzweise die lateinische Pluralform - oder man ist kreativ ("Indexe"), fällt damit aber möglicherweise als Sprach-Revoluzzer auf. Ähnlich übrigens mit dem Wort Atlas und dem Plural Atlanten^[1].

Aber das Zehennägel-Aufrollen, das ich im anderen Beitrag beklagt habe, stellt sich auch bei penetranten, hartnäckigen Fehlern in reinem Deutsch ein. Wenn etwa jemand behauptet, er habe ein Plural-s angehangen^[2], läuft mir jedesmal ein Schauer den Rücken runter. Oder wenn Standard immer wieder mit t am Ende geschrieben wird.

Ich selbst orientiere mich an diesen von mir definierten hervorgehobenen Markern. Und ich hoffe sehr, das diejenigen die meinen Thread lesen, den Sachverhalt besser verstehen können eben durch diese Textauszeichnungen. Mir jedenfalls geht es so.

Was mich angeht, erreichst du genau das Gegenteil. Jedesmal, wenn eine vom gewohnten Schriftbild oder vom Standard abweichende Schreibweise auftaucht (ich vermeide absichtlich das Adjektiv falsch), stockt der Lesefluss, man stutzt einen Moment: Äh halt, was war das? Deswegen brauche ich zum Lesen eines derart "kreativ" geschriebenen Textes deutlich länger.

Ich hoffe du verstehst mein Anliegen für das Forum

Dem Forum bzw. seinen Lesern wäre vermutlich mehr geholfen, wenn du dich an allgemeine Konventionen halten würdest.

Schönes Wochenende,
 Martin

---

1. Die Rechtschreibdeform erlaubt mittlerweile auch Atlasse. Grauenhaft! ↩︎

2. Es heißt angehängt! ↩︎

[MB]

moin,

nur um das nochmal klarzustellen: [...]

Ist mir bewusst.

Ich selbst orientiere mich an diesen von mir definierten hervorgehobenen Markern. Und ich hoffe sehr, das diejenigen die meinen Thread lesen, den Sachverhalt besser verstehen können eben durch diese Textauszeichnungen. Mir jedenfalls geht es so.

Was mich angeht, erreichst du genau das Gegenteil. [...]

Sorry. Ich habs hier und da auf Grund der Reaktionen geahnt.

Ein konkretes Beispiel um meine Absicht zu verdeutlichen: Wenn ich "Klassen" schreibe und meine "Instanzen" und ich verwende Ausdrücke wie new Foobar, dann passt da in meiner Ausführung für den Leser etwas nicht - ich glaube @pl oder du hast Nachgehackt. Wenn ich das nicht veranschaulicht hätte, dann hätte es bestimmt lange gedauert, bis das Forum verstanden hat, das ich "Instanzen" meine, aber "Klassen" geschrieben habe.

Ich hoffe du verstehst mein Anliegen für das Forum

Dem Forum bzw. seinen Lesern wäre vermutlich mehr geholfen, wenn du dich an allgemeine Konventionen halten würdest.

Sorry. Ich nehm' ja fleißig und konsequent an Logo teil 😀.

lgmb

[Matthias Apsel]

Hallo MB,

Wir sind hier nicht im Lateinunterricht ;-).

Aber im SELF-Forum. Hier erhält man häufig ergänzende Informationen. Ich habe mich zum Beispiel gefragt, warum es „ultima ratio“ heißt.

Bis demnächst
Matthias

[Der Martin]

Hallo Matthias,

Ich habe mich zum Beispiel gefragt, warum es „ultima ratio“ heißt.

weil - auch wenn die Endung das nicht vermuten lässt - auf -io endende Wörter im Lateinischen grundsätzlich (?) weiblich sind, wie eben ratio, conclusio oder conditio.

Schönen Abend noch,
 Martin

[Der Martin]

Hallo,

[...] Naja, nicht immer: Vor allem bei Fachbegriffen aus dem Lateinischen weicht der Plural oft vom einfachen Anhängen eines s ab, z.B. Index, Indices (wobei die Pluralform Indexe auch gelegentlich vorkommt).

Wir sind hier nicht im Lateinunterricht ;-).

das spielt keine Rolle. Wer Fremdworte verwenden will, sollte sie bitte richtig verwenden.

Um dein beispiel auf zu greifen

Meintest du: aufzugreifen?

würde ich sowas schreiben: Index's

Autsch. Da rollen sich meine Zehennägel auf.

Ciao,
 Martin

[MB]

moin,

Wir sind hier nicht im Lateinunterricht ;-).

das spielt keine Rolle. Wer Fremdworte verwenden will, sollte sie bitte richtig verwenden.

bin da ganz bei dir!

Um dein beispiel auf zu greifen

Meintest du: aufzugreifen?

jepp. Sorry dafür und Dankeschön 😀

würde ich sowas schreiben: Index's

Autsch. Da rollen sich meine Zehennägel auf.

Wenn man aus der Lateinecke kommt, würden sich bei mir auch die Zehennägel hoch rollen. Außerdem ist mein Beispiel index ja auch exemplarisch, mehr nicht.

lgmb

[Der Martin]

Hi,

noch einen zur Ergänzung:

Vor allem bei Fachbegriffen aus dem Lateinischen weicht der Plural oft vom einfachen Anhängen eines s ab, z.B. Index, Indices (wobei die Pluralform Indexe auch gelegentlich vorkommt).

ein sehr häufig auftretendes Beispiel für falsche Pluralbildung ist das aus dem Lateinischen stammende Wort Status. Nur zu oft sieht man, wie Leute sich für gebildet halten und als Plural Stati schreiben. Und sogar Statusse habe ich schon gelesen.
Nein! Der Plural von Status ist Status. Und zwar mit langem u, deshalb auch manchmal als Statūs geschrieben (waagrechter Strich über dem u).

Und wer sich unsicher ist, sollte lieber "Zustände" schreiben. ;-)

Schönes Wochenende,
 Martin

[Matthias Apsel]

Hallo Der Martin,

Nein! Der Plural von Status ist Status. Und zwar mit langem u, deshalb auch manchmal als Statūs geschrieben (waagrechter Strich über dem u).

Passus ebenso.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Passus ebenso.

Nicht Passagen?

Gruß
Kalk

[pl]

Neben bei: Ich hasse Array's flut. Meiner Erfahrung nach sind Array's sehr unspezifisch und ich mag sie garnicht! Man muss wissen, welche struktur das Array hat, welchen Datentyp ein Feld hat, obs Key-Value-Paare sind, usw.

Objekte sind Arrays! Und natürlich kommt es auf eine zweckmäßige Strukturierung an, das ist da A und O der Objektorientierten Programmierung! Und diese Objekte sind nicht nur Schlüssel-Werte-Paare sondern können sehr umfangreich sein.

Mit einer ConstructorInjection hat man das Problem nicht.

Wie bitte? Das ist doch der Sinn und Zweck einer Injektion, Instanzen fremder Klassen als Eigenschaften der eigenen Instanzen zu transportieren. Objekte und Methoden sind das was den wahlfreien Zugriff zum Hauptspeicher vermittelt.

Von daher kann es auch nicht das Ziel von OOP sein, möglichst viele Objekte (Arrays) zu haben sondern möglichst Wenige! Und wie schonmal gesagt: Ein Objekt referenziert Daten, und andere Objekte. Damit hat jede Methode auch Zugriff auf die Daten. Datentypen sind völlig nebensächlich, bei Webanwendungen hast Du es eh nur mit Strings zu tun.

MFG

[Christian Kruse]

Hallo pl,

Objekte sind Arrays!

Nein. Einfach nein.

Freundliche Grüße,
Christian Kruse

[pl]

Beispiel für Aggregation (Objekte in Objekten)

function _fetch_mesg($mesgid){
    if( ! isset($this->STH_FETCH_MESG)  ){
        $this->STH_FETCH_MESG = $this->DBH->prepare("SELECT * FROM $this->TABN WHERE mesgid=?");
    }
    $this->STH_FETCH_MESG->execute(array($mesgid));
    $mesg = $this->STH_FETCH_MESG->fetchAll();
    if( empty($mesg) ){ dd("Diese Nachricht existiert nicht!"); }
    return $mesg[0];
}

Wobei man die Struktur für die Statements weiter verbessern kann: $this->STATEMENTS was den Vorteil hat, daß man ggf. alle Statements mit einmal löschen kann. Aber das ist ja nur ein Beispiel und wie man sehen kann steckt in $this->DBH ein weiteres Objekt, das PDO Objekt. Letzteres wird zur Laufzeit eingebunden, man könnte es auch über den Konstruktor injezieren sofern es über die gesamte Anwendung benötigt wird.

Des Weiteren

    function param($name = ''){
        if(! isset($this->CGI) ){
            require "CGI.php";
            $this->CGI = new CGI();
        }
        return $this->CGI->param($name);
    }

auch ein typisches Beispiel für eine spätere Aggregation/late Delegation. Das CGI-Objekt wird erst eingebunden wenn die Methode param() aufgerufen wird. In Fakt beim ersten Aufruf dieser Funktion.

Das sind nur mal eben 2 Beispiele wie man seine Modells in Arraystrukturen abbilden kann. Deiner Kreativitär sind hier keine Genzen gesetzt.

MFG

[pl]

PS

Des Weiteren

    function param($name = ''){
        if(! isset($this->CGI) ){
            require "CGI.php";
            $this->CGI = new CGI();
        }
        return $this->CGI->param($name);
    }

auch ein typisches Beispiel für eine spätere Aggregation/late Delegation. Das CGI-Objekt wird erst eingebunden wenn die Methode param() aufgerufen wird. In Fakt beim ersten Aufruf dieser Funktion.

Eine solche Vorgehensweise wird auch Lazy Delegation genannt. Lazy weil die Aggregation (Instanz einer fremden Klasse als Eigenschaft der eigenen Klasseninstanz einbinden) später erfolgt also nicht als Injektion über den Konstruktor. Delegation weil die Methode der CGI-Instanz delegiert und damit zu einer eigenen Methode gemacht wird. D.h., die param()-Funktion die eine Methode der CGI-Instanz ist, wird so aufgerufen als wäre sie eine eigene Funktion.

Natürlich könnte man genau das auch per Vererbung erreichen, da erbt man jedoch sämtliche Methoden der Basisklasse.

Und natürlich kann man Lazy Delegation auch über Traits abwickeln. Man borgt sich sozusagen Methoden fremder Klassen (fremd heißt hier NICHT verwandt) und erstellt hierzu auch die entsprechenden Instanzen. Wie die Datenstrukturen im Inneren dieser Instanzen aussehen ist uninteressant, dafür gibt es eine API die man nutzt.

MFG

[MB]

moin,

Ich nehme an, das deine Beispiele speziell aus deinem Framework sind. Ok, schön und gut. Wenn man deinen Beispielen folgen will, müsste man - so denke ich - dein Framework verstehen und deinen eigenen Stil kennen, der, wie du zu verstehen gegeben hast, keiner Konvention folgt, was du ja in diesem Thread geschrieben hast. Man säße da Wochen lang dran, und wenn du mich kennst - mittlerweile müsstest du das - dann säße ich vierfach solange dran um deinen Weg zu verstehen. Und wie du selbst in diesem Thread gesagt hast hast du deinen eigenen Stil Das ist meine Einschätzung von deinem konkreten Beispiel.

Generalisiere doch deine Beispiele in Foren.

lgmb

PS: Ich habe gelesen das du ja ein Manual zu deinem Framwork gemacht hast. Vorbildlich!.

[pl]

Meine Beispiele sind trivialer Code. Eigenschaften von Objekten verwenden, das ist in der OOP etwas sehr Grundlegendes. Es hängt jedoch von Deinem handwerklichen Geschick ab, was Du damit machst und zwar so, daß Dein Code reproduzierbar ist. MFG

[Rolf B]

Hallo pl,

Von daher kann es auch nicht das Ziel von OOP sein, möglichst viele Objekte (Arrays) zu haben sondern möglichst Wenige!

Zur Gleichsetzung von Objekten und Arrays: Da verwechselst Du Implementierung und Konzept. In dynamischen Sprachen wie PHP, Perl und JS wird ein Objekt als ein Dictionary mit spezieller Semantik angesehen (ich strapaziere den Begriff „spezielle Semantik“ jetzt vielleicht etwas arg). Und auch Arrays werden als Dictionary mit spezieller Semantik implementiert. Das ist nicht effizient, und darum wurden gibt es die Das gilt aber in anderen Sprachen wie Java oder C# nicht. Und es bedeutet keinesfalls, dass Objekte, Arrays und Dictionaries konzeptionell das gleiche sind.

Das Ziel "möglichst viele Objekte" sollte man nie verfolgen, richtig. "Möglichst wenige" ist aber auch nicht die Leitlinie. Sondern: die richtige Menge. Leitlinie ist das Single Responsibility Prinzip. Das Problem ist: wenn man aus der prozeduralen Welt kommt und dann anfängt „mit Objekten“ zu programmieren, entsteht daraus noch lange keine OOP-Anwendung. Die von Dir vertretene Sichtweise hatte ich auch lange und ein paar Klebefäden werde ich nicht los. Aber sie ist immer noch prozedural, nicht objektorientiert.

Datentypen sind völlig nebensächlich, bei Webanwendungen hast Du es eh nur mit Strings zu tun.

Integer (Number), Date und Bool kommen zumindest noch hinzu. Typen dienen unter anderem dazu, mit der Runtime eine möglichst effiziente Repräsentation der genutzten Daten zu vereinbaren. Und dann sollte man bedenken, dass jede Klasse ebenfalls ein Typ ist!

Rolf

[MB]

moin,

Neben bei: Ich hasse Array's flut. Meiner Erfahrung nach sind Array's sehr unspezifisch und ich mag sie garnicht! Man muss wissen, welche struktur das Array hat, welchen Datentyp ein Feld hat, obs Key-Value-Paare sind, usw.

Objekte sind Arrays!

Nein. Es heistes nicht Objekt gleich Array. Du kannst Objekte in PHP zu einem Array casten und umgekehrt.

[…] Und natürlich kommt es auf eine zweckmäßige Strukturierung an, das ist da A und O der Objektorientierten Programmierung!

Sage mir etwas was ich noch nicht weis. Ich "fühle" mich irgendwie verarscht. Ich fühle mich so behandelst, als ob mir nicht klar wäre, wie man ein mal eins rechnet. Sorry aber so fühle ich mich von Dir behandelt.

Sie dir meinen exemplarischen Code im Thread an. Da weist du, wo du mich fachtechnisch abholen kannst. Übrigens das viel mir extreeem häufig auf, das du deiner Arguimentation so aufbaust.

Mit einer ConstructorInjection hat man das Problem nicht.

Wie bitte? Das ist doch der Sinn und Zweck einer Injektion, Instanzen fremder Klassen als Eigenschaften der eigenen Instanzen zu transportieren. Objekte und Methoden sind das was den wahlfreien Zugriff zum Hauptspeicher vermittelt.

Nichts anderes habe ich gesagt. Liest du eigentlich was ich geschrieben habe? Es sei den ich habe dich wie so oft falsch vertstanden. Sorry

Von daher kann es auch nicht das Ziel von OOP sein, möglichst viele Objekte (Arrays) zu haben sondern möglichst Wenige!

s.o.

Und wie schonmal gesagt […]

s.o.

lgmb

[pl]

moin,

Neben bei: Ich hasse Array's flut. Meiner Erfahrung nach sind Array's sehr unspezifisch und ich mag sie garnicht! Man muss wissen, welche struktur das Array hat, welchen Datentyp ein Feld hat, obs Key-Value-Paare sind, usw.

Objekte sind Arrays!

Nein.

Siehst Du, Diese Antwort zeugt von einem fehlenden Abstraktionsvermögen. Genau das ist aber beim Programmieren wichtig. Und was Objekte betrifft, natürlich stecken da Arrays drin

$this->CGI->PARAM['action'];
$this->BIN[$url]['title'];

Und ein Dumper zeigt die ganze Baum-Struktur. Jeder Programmierer weiß was eine Baumstruktur ist und käme niemals auf die Idee, daß es sich dabei um ein Naturprodukt handelt.

Schönen Sonntag

[MB]

moin,

Neben bei: [...]

Objekte sind Arrays!

Nein.

Siehst Du, Diese Antwort zeugt von einem fehlenden Abstraktionsvermögen. [...]

Weißt du das? Hast du meinen Code Haarklein Untersucht, um mir das zu Attestieren? Ich denke du pauschalisierst extrem.

Versteh mich Bitte nicht falsch. Ich bin mir sicher, das du mit deiner Aussage keine böswillige Absicht hegst. Aber du bist auf negative weise extrem überschwenglich. Mir machst du auf alle Fälle den Eindruck, weil du lehrenderweise alles runterbetest, was sehr oft nicht zum Thread passt. Und du machst diesbezüglich Stur weiter, obwohl andere Kommentatoren versuchen Dir Einhalt zu gebieten.

Und das was du Runterbetest ist manchmal einfach Falsch - nicht immer. Ich bin mir Sicher, das du manche falsche Lehrinhalte anders meinst, als wie du es schreibst, ohne Frage und möglicherweise ist das was du meinst Korrekt. Aber du verstehst das einige Profis deine falsch Lehrinhalte in der Luft zerreißen.

Schönen Sonntag

Wünsche ich Dir auch @pl

lgmb

[Gunnar Bittersmann]

@@MB

Du hast 20 Jahre Forumsgeschichte sehr treffend zusammengefasst.

Nur beim letzten Satz bin ich mir nicht sicher:

Aber du verstehst das einige Profis deine falsch Lehrinhalte in der Luft zerreißen.

LLAP 🖖

[MB]

moin,

Ein Anmerkung noch von mir:

Es passiert hier häuftig das man sich bekriegt um seien festgefahrenen Standpunkt zu vetreten von dem man nicht weicht. Das passiert uns allen, bei dem einen mehr bei anderen weniger. Und das allein nur durch verdammte Missverständnisse!

Wenn man einen zusammenhanglose Kommentar-Reaktion auf seinen Kommentar bekommt, und das sofort als Angriff oder unprofessionalität abtun, wäre es ratsam, nochmal auf diese Kommentar-Reaktion in sachlicher Form einzugehen und zu fragen. So können Missverständnisse die auftreten sofort ausgeräumt und im Keim erstickt werden. Es wäre echt wünschenswert. Diese Bitte geht an alle, auch an mich, da ich manchmal der Selben "sch**ße" unterliege wie je jeder der Atmet und sich als Mensch schimpft.

Schönes Wochenende 😉

lgmb

[pl]

Es kommt immer darauf an, das Wesentliche zu erkennen. Genau daran lasse ich mich auch hier im Forum leiten. Also es kommt darauf an zu erkennen wo das eigentliche Problem liegt. Und hier noch einmal ein trivialer Code:

function param($name = ''){
    if(! isset($this->CGI) ){
        require "CGI.php";
        $this->CGI = new CGI();
    }
    return $this->CGI->param($name);
}

Welcher eine interessant Altenative zu Dependency Injection zeigt.

Das Problem in DI: Eingepflanzte Objekte sind außerhalb der Kapselung veränderbar, der Grund dafür ist, sie sind keine Kopien sondern Referenzen.

Og. trivialer Code löst diess Problem. Und zwar ohne daß die Objektstruktur geändert werden muss. Und natürlich kann man eine solche Methoden (Stichwort Factory) auch in Traits auslagern.

Du siehst also, hier fallen eine ganze Menge Fachbegriffe. Es kommt darauf an zu verstehen was sich dahinter verbirgt. Kein Astronom der Welt würde die Milchstraße für ein Molkereiprodukt halten (Danke Hoimar von Ditfurth)

MFG

[MB]

moin,

Hier

lgmb

[Rolf B]

Hallo pl,

Es kommt immer darauf an, das Wesentliche zu erkennen.

was in diesem Fall ist: Du faselst.

Was Du zeigst, ist keine Alternative zu DI, sondern die in grellen Farben gezeichnete Darstellung des Problems, das DI lösen will: Festgebackene Abhängigkeiten, die Unit-Tests verhindern und Flexibilität nehmen. In deinem Fall ist es ein Zwieback: außer zur CGI Klasse gibt's auch noch die Abhängigkeit zum Sourcefile, d.h. das Unterschieben einer CGI-Klasse aus CGI_Emulator.php ist auch nicht mehr möglich.

Eigentlich ist es in deinem FW ja eine großartige Idee, die HTTP Request/Response Themen auszulagern. So kann man die Controllerklasse über automatisierte Tests laufen lassen und das CGI Umfeld simulieren. Aber genau dafür muss man das CGI Objekt injizieren können. Da ein Controller es vermutlich in 99% aller Fälle brauchen wird, dürfte es wenig sinnvoll sein, dieses Objekt so wie oben gezeigt lazy zu beschaffen. Das Beschaffen der CGI Instanz gehört in den Konstruktor. Man KANN es so bauen, dass eine fehlende CGI Injektion bewirkt, dass der Controller sich das CGI Objekt aus einer Default-Implementation holt. Aber niemals nicht so wie in deiner Methode. Die ist ein perfektes Beispiel für ignoriertes SRP.

Rolf

[pl]

Neben bei: Ich hasse Array's flut. Meiner Erfahrung nach sind Array's sehr unspezifisch und ich mag sie garnicht! Man muss wissen, welche struktur das Array hat, welchen Datentyp ein Feld hat, obs Key-Value-Paare sind, usw. Mit einer ConstructorInjection hat man das Problem nicht.

Ich sehe Dein Hauptproblem im richtigen Umgang mit komplexen Datenstrukturen. Da gibts nur Eines: Üben. Also nicht den Hass ausüben sondern den Umgang üben. Das muss sozusagen in Fleisch und Blut übergehen wie Kuppeln, Schalten, Gas geben. Das sind Fertigkeiten die muss man sich selbst aneignen.

Viel Erfolg!

[Mitleser]

Ich sehe Dein Hauptproblem [...]

Deines sehe ich ich unbändiger Ignoranz. Arbeite dran.

Viel Erfolg!

Dir auch!

[MB]

moin,

Neben bei: Ich hasse Array's flut [...]

Ich sehe Dein Hauptproblem im richtigen Umgang mit komplexen Datenstrukturen. [...]

s.o.

lgmb

[pl]

moin,

Neben bei: Ich hasse Array's flut [...]

Ich sehe Dein Hauptproblem im richtigen Umgang mit komplexen Datenstrukturen. [...]

s.o.

Ok, da lag ich ja richtig. Abstraktion ist auch wichtig, wenn es darum geht, bestimmte Entwurfsmuster in trivialen Code (siehe mein Beispiel Delegation) zu erkennen. Oder anders ausgedrückt: Anhand von Code erkennen daß der Code ein Interface implementiert ohne daß Interface davorsteht. Dasselbe gilt natürlich auch für Traits, die konnte man auch mit PHP schon bauen ohne daß man Trait davorschreiben musste.

Und natürlich ist eine abstrakte Denkweise auch notwendig wenn man bestimmte Entwurfsmuster selbst umsetzen will.

Objekte, Instanzen von Klassen, können in der Praxis auf den ersten Blick mächtig gewaltig aussehen und bspw. mehrere Megabyte an Daten transportieren. Ich habe solch ein Aggregat (Perl) mal einem Kollegen (PHP) gezeigt der war zunächst erschrocken. Hat aber letztendlich keine 5 Minuten gebraucht um damit selbstständig weiterzumachen. Am Ende war er sogar begeistert und meinte daß es eben genau diese Dinge sind die man nicht in der Schule lernt. Eben, weil es Fertigkeiten sind.

Schönen Sonntag

[MB]

moin,

moin,

Neben bei: Ich hasse Array's flut [...]

Ich sehe Dein Hauptproblem im richtigen Umgang mit komplexen Datenstrukturen. [...]

s.o.

Ok, da lag ich ja richtig.

Hier

lgmb

[MB]

moin,

[...] Irgendwelche Entwurfsmuster nachzubauen bringt da gar nichts.

Meines Wissens, ist mein SQL Projekt "streng genommen" nach keinem Entwurfsmuster nachempfunden, wenn man mal von der ConstructorInjection absieht, was gefühl jeder Programmierer anwendet, der im OOP unterwegs ist. NICHT "streng genommen" kann man grob ein BuilderPattern und DecoratorPattern ausmachen, weil ich es in der Form strukturiert habe, aber streng genommen sind keins von den beiden in meinem Projekt vorhanden.

lgmb

[pl]

Aufgrund meiner Erfahrung (ich habe 3 Frameworks entwickelt und zwar selbständig!) ein Hinweis zu Injektionen: Bei einem Interface (IF) steht die Reihenfolge fest in welcher die Methoden des IF aufgerufen werden. So wird man z.B. ein PDO Objekt zweckmäßigerweise in der ersten IF-Methode oder vor dem Aufruf der ersten IF-Methode injezieren damit man dieses Objekt in den nachfolgenden Methoden zur Verfügung hat. Diese Injektion kann später erfolgen, also nachdem die Main-Instanz gebildet wurde.

Braucht man jedoch die Methoden einer nichtverwandten Klasse durch die gesamte Anwendung hindurch, wird die Instanz dieser Klasse in den eigenen Konstruktor hineingereicht (injeziert).

Und wie gesagt, Deine Erfahrungen musst Du selber machen. Deswegen ja ist Programmieren keine Kunst sondern ein Handwerk was man eben nur selber lernen kann wenn man es selber macht.

So wird man auch am Ende eigener Entwicklungen sämtliche Muster der GoF in seinem eigenen Code vorfinden, auch dann wenn man gar nicht vor hatte nach einem bestimmten Muster entwickeln zu wollen.

Und siehst Du, genau deswegen sind Traits in PHP und Interfaces in PHP keine Besonderheit von PHP sondern allgemeingültige Dinge die man auch ganz anders umsetzen kann als wie PHP das vorschreibt. Bsw. ist eine externe Methode die erst per __call() aus dem Dateisystem nachgeladen wird bereits ein Trait. Und auch in solchen Methoden kann man Instanzen nicht verwnandter Klassen nachladen oder injezieren.

Genausogut kann man auch ein Interface mit Klassen aufsetzen ohne daß man das Schlüsselwort interface dazu braucht.

MFG

[Rolf B]

Hallo pl,

Bei einem Interface (IF) steht die Reihenfolge fest in welcher die Methoden des IF aufgerufen werden

Das klingt jetzt merkwürdig, aber ich denke, ich weiß was Du meinst: Für eine bestimmte Aufgabe, die man mit Hilfe des Interfaces erledigen will, ist eine bestimmte Reihenfolge von Methodenaufrufen auf diesem Interface erforderlich. Wenn Du sagen wolltest, dass sämtliche Methoden eines Interface stets in einer fixen Reihenfolge zu rufen sind, dann würde das meinen eigenen Erfahrungen im Gebrauch und in der Bereitstellung von Interfaces widersprechen.

Injizieren kann man grundsätzlich auf zwei Arten: Bei Konstruktion oder nachher. Unity von Microsoft unterstützt z.B. Injektion im ctor, über Properties oder über Methoden. Es injiziert aber immer alles, wofür es eine Kanüle findet. Deshalb habe ich auch schon Injektionsmethoden gebaut und vor Unity versteckt (bzw. auf eine Bekanntgabe an Unity verzichtet), um sie bedarfsweise nutzen zu können.

Dass Traits und Interfaces Ideen sind, die nicht auf PHP beschränkt sind, ist klar - aber nicht jedes Programmierkonzept lässt sich in jeder Sprache elegant umsetzen. Wenn ich ein Konzept nur mit mühsamen Krücken nutzen kann, dann macht das den Code eher schlechter als besser. Traits wären z.B. in C# vor .net 3.0 ohne einen Code-Generator nicht sinnvoll machbar gewesen. Das spricht dann wieder für dein Handwerkskonzept: man muss wissen, was der eigene Werkzeugkasten hergibt, und um man im Zweifelsfall einen Meißel in der Kiste hat, mit dem man auch mal eine Schraube eindrehen kann.

So wird man auch am Ende eigener Entwicklungen sämtliche Muster der GoF in seinem eigenen Code vorfinden

Sicherlich. Wenn man das vom Pattern gelöste Problem hat, wird man das Pattern im Zweifelsfall selbst entwickeln. Das ist ja keine Raketenwissenschaft. Es ist Handwerk. Sprich: Standardlösungen für Standardprobleme, die der Handwerker ohne langes Nachdenken anwenden kann. Das ist die Idee des GoF Buchs - man lernt diese Standardlösungen kennen. Das spart schlichtweg Zeit, und hilft anderen, die GoF ebenfalls kennen, den eigenen Code zu verstehen. Machmal bringt einen GoF auch auf elegante Lösungen für Probleme, für die man vorher nur eine mühsame Bastellösung hatte. Wenn man andererseits zwanghaft auf GoF Patterns zurückgreift, weil man meint, für alles ein fertiges Pattern nutzen zu müssen, hilft es dem Code überhaupt nicht (ich denke da an einen Klempnerlehrling, der eine 2m Rohrleitung aus 50 Fittings zusammensteckt...).

Rolf

[pl]

Ich habe eine Klassengruppe, die, per Instanziierung, einen SQL Teilstring erzeugen. Ich nenne z.B. In, Between, Cases, Arithmetic, LogicContainer aus der Klassengruppe.

Das kann auch eine Klasse ganz allein lösen. Mein Ansatz wäre, eine Basisklasse zu entwerfen und die Aufgabe per Vererbung zu spezialisieren.

Alle Klassen müssen über die selben Methoden verfügen:

Das klingt nach Interface! Also werden diese Methoden in der Basisklasse definiert. Und in der Subklasse die von der Basiklasse erbt spezialisiert.

MFG

[MB]

moin,

Ich habe eine Klassengruppe, [...]

Das kann auch eine Klasse ganz allein lösen. [...]

s.o.

Alle Klassen müssen über die selben Methoden verfügen:

Das klingt nach Interface! [...]Also werden diese Methoden in der Basisklasse definiert. Und in der Subklasse di

s.o.

lgmb

[dedlfix]

Tach!

Alle Klassen müssen über die selben Methoden verfügen:

protected function addString ( string $string ) : void;

public function getString () : string;

Kann man dieses Klassen Gebildes mit Traits oder mit einer Elternklasse realisieren? Ich sehe da Pros & Cons: Hab ihr erfahrungen?

Wenn etwas zu dem gehört, das eine Klasse ausmacht, dann würde ich es ihr direkt einbauen. Oder über Vererbung mitgeben, wenn der Code wiederverwendet wird. Die Basisklasse wird dabei abstrakt erstellt, wenn sie nicht selbständig verwendet werden kann. Code, der in nicht zusammenhängenden Klassen wiederverwendet werden soll, kommt in Traits. Falls überhaupt und sich kein besseres Konstrukt findet (Service zum Beispiel).

Ich für meinen Teil habs' mit einer abstrakten Elternklasse realisiert, von der alle Klassen erben und dann die Elternklasse mit Traits versehen. So spart man sich gehörig schreibarbeit.

Schreibarbeit ist nicht das Hauptkriterium, sondern das Veständnis des Codes für Außenstehende, also auch für dich in drei Wochen, und die Wartbarkeit. Damit ergibt sich quasi von selbst, dass man kein Dopplungen einbaut.

dedlfix.

[MB]

moin,

Code, der in nicht zusammenhängenden Klassen wiederverwendet werden soll, kommt in Traits. Falls überhaupt und sich kein besseres Konstrukt findet (Service zum Beispiel).

Ich hab zu erst diesen Code als Service Klassen verwendet.

Ich für meinen Teil habs' mit einer abstrakten Elternklasse realisiert, von der alle Klassen erben und dann die Elternklasse mit Traits versehen. So spart man sich gehörig schreibarbeit.

Schreibarbeit ist nicht das Hauptkriterium, sondern das Veständnis des Codes für Außenstehende, also auch für dich in drei Wochen, und die Wartbarkeit.

Ja, auch, Sorry. Wollte ich im Thread hingeschrieben haben, habs aber vergessen 😕.

lgmb

[pl]

@MB

weil DI hier mehrfach angesprochen wurde:

Wir haben ein PDO-Objekt erstellt und übergeben das dem Konstruktor der eigenen Klasse:

    $main = new main($pdo);

Wie wir wissen, ist bei diesem PDO-Objekt das Attribut PDO::ATTR_DEFAULT_FETCH_MODE auf PDO::FETCH_ASSOC gesetzt. Nun schauen wir doch mal was passiert, wenn wir dieses Attribut nach der Übergabe an den Konstruktor ändern:

    $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_OBJ);

Hierzu der restliche Code zum Verständnis.

$mesg = $main->fetch_mesg(88); # Array erwartet?
print_r($mesg);                # wir haben ein Objekt bekommen!
class main{
    function __construct($pdo){
        $this->PDO = $pdo;
    }

    function fetch_mesg($mid){
        $sth = $this->PDO->prepare("select * from forum where mesgid=?");        
        $sth->execute(array($mid));
        $mesg = $sth->fetchAll();
        return $mesg[0];
    }
}

Es zeigt sich, daß die Änderung am PDO auch dann wirksam werden, wenn diese Änderung nach der sog. Dependency Injection erfolgt. Die Erklärung hierfür ist ganz einfach: Das PDO-Objekt wird in der Eigenschaft $this->PDO referenziert. Das heißt, die Eigenschaft beeinhaltet keine Kopie sondern eine Referenz.

Daraus ergibt sich eine wichtige Schlussfolgerung in Sachen Dependency Injection: Das injezierte Objekt kann im Nachhinein geändert werden. Und zwar außerhalb der Kapselung!

MFG

[dedlfix]

Tach!

Wie wir wissen, ist bei diesem PDO-Objekt das Attribut PDO::ATTR_DEFAULT_FETCH_MODE auf PDO::FETCH_ASSOC gesetzt.

Das stört uns aber nicht weiter, weil beim Aufruf von PDOStatement::fetch() der Fetch-Style individuell angegeben werden kann.

Nun schauen wir doch mal was passiert, wenn wir dieses Attribut nach der Übergabe an den Konstruktor ändern:

Wenn man trotz der Möglichkeit der individuellen Angabe auf den Defaultwert setzt, und diesen - bezogen auf das PDO-Objekt - globalen Wert ändert, dann kann das durchaus ein Problem werden. Ist dann aber persönliches Pech, weil vermeidbar.

Es zeigt sich, daß die Änderung am PDO auch dann wirksam werden, wenn diese Änderung nach der sog. Dependency Injection erfolgt. Die Erklärung hierfür ist ganz einfach: Das PDO-Objekt wird in der Eigenschaft $this->PDO referenziert. Das heißt, die Eigenschaft beeinhaltet keine Kopie sondern eine Referenz.

Dass bei Objekten Referenzen übergeben werden, ist das übliche Verhalten.

Daraus ergibt sich eine wichtige Schlussfolgerung in Sachen Dependency Injection: Das injezierte Objekt kann im Nachhinein geändert werden. Und zwar außerhalb der Kapselung!

Ist nur kein spezielles Problem der DI.

dedlfix.