5 comments on “Stefan Lieser über Clean Code Developer – Anwendungsentwickler-Podcast #102”

1. Marcel sagt:

   25. August 2017 um 11:43:55 Uhr

   Hi Stefan,

   Ich hab einen scheinbaren Widerspruch entdeckt, zwischen den Vorstellungen in OOP und den Dependency Injection.
   In Ihrem Audiocast zum Thema OOP gehen Sie auf die Notwendigkeit ein, dass instanzierte Objekte immer gültige Membervariablen ( genauer Begriff fehlt mir im Moment ) haben müssen. Konkret ging es darum NULL-Exceptions zu verhindern in den man ungültige Werte im Objekt hat.

   Mein Beispiel: Datenbank-Klasse
   Nun steh ich vor einem Problem. Wenn ich vorab alles im Konstruktor organisiere, kann ich im erzeugten Objekt gleich meine SQL-Anfrage beim instanzieren übergeben. Im Objekt sind damit keine ungültigen Membervariablen.

   Wenn ich aber das Dependency Injection anwenden möchte und mein Objekt außerhalb erzeuge, so kann ich die SQL-Anfrage nicht schon bei der Instanzierung mitgeben, denn ich will ja das Datenbank-Objekt dem Konstruktor einer Anderen Klasse ( z.b. Worker ) übegeben, die mit dem Datenbank-Objekt arbeiten soll.

   Jetzt ist es notwendig in der Datenbankklasse, statt im Konstruktor eine eigen Methode zu definieren, die das SQL-Statement entgegennimmt. Damit hab ich aber ein Ungültiges Objekt erzeugt, bevor es in meiner Worker-Klasse verwendet wird.

   Hab ich hier eine grundsätzlichen Denkfehler? 🙂

2. Stefan Macke sagt:

   26. August 2017 um 11:36:00 Uhr

   Hallo Marcel,

   warum bekommt deine Datenbank-Klasse denn EINE SQL-Abfrage übergeben? Diese Frage würde ich mir stellen. Denn dann ist sie ja nicht wiederverwendbar. Ich würde – ohne deinen Code zu kennen – erwarten, dass die Klasse beliebige Statements entgegennehmen und ausführen kann. Und dann dürften diese gar nicht in Instanzvariablen abgelegt werden, sondern sind nur während des Methodenaufrufs als Parameter gültig.

   Aber selbst in deinem Fall könntest du doch die Datenbank-Klasse mit dem SQL-String erzeugen (gültig) und dann das Objekt als Parameter im Konstruktur an die Klasse weitergeben, die es nutzen soll. Die Instantiierungsreihenfolge dreht sich nur um: SQL -> DB-Objekt -> Fachobjekt.

   Viele Grüße!
   Stefan

3. Marcel sagt:

   26. August 2017 um 22:44:39 Uhr

   Ich glaub ich bin da weniger Methodisch herran gegangen sondern mehr praktisch oder besser bequem, was den Code anging. Ich wollte halt so wenig wie möglich schreiben um eine Datenbankabfrage mit SQL zu erledigen. Ich nutze in PHP PDO, was selbst schon eine Klasse ist. Hier wird bzw. kann auch ein Objekt erzeugt werden. Mir was das ganze drumrum einfach zu viel, also Parameter setzen und immer wieder das gleiche ausführen bevor die eigentlich eAbfrage kommt. Mein Grundgedanke in dem Moment, wo ich die Klasse erstellt hab war „was kann ich die Klasse machen lassen und was brauch ich maximal für meine Standardabfragen“ Da blieb dann nurnoch der SQL-String und die optionale Parameterliste ( für Prepare Statements ) übrig.

   Ich les aber schon aus Deiner Antwort raus, dass ich sowieso meinen grundsätzlichen Denkansatz falsch betrachtet hab. Alternativ zur Instanzierung ist es also besser die Klasse bzw Ihre Methoden statisch aufzurufen?

   In der „Worker“-Klasse entsteht natürlich erst der String als SQL-Statment.
   Welche Vorgehensweise würdest Du vorschlagen um vorab zu untersuchen was und ob etwas in einen Konstruktor kommt. So genommen wäre es scheinbar besser Nichts in den Konstruktor zu lassen, wenn man nie weiss, ob man die daraus ein Objekt erzeugt, dass man von außen einer anderen Klasse übergeben will.

   Praxis:
   Ich fand das hier bisher grad recht übersichtlich. ( Innerhalb von Worker )

   $db = new DBService( „SELECT * FROM hallo“ );
   print_r( $db -> getResult() );

   Ansonsten wäre es immer so, Ohne Konstruktor:

   $db = new DBService();
   print_r ( $db -> getResult( „SELECT * FROM hallo“ ) ) ;

   oder:

   $db = new DBService();
   $db -> stm( „SELECT * FROM hallo“ );
   print_r ( $db -> getResult() ) ;

   Vielen Dank für Ihre Rückmeldung! Obwohl alles irgendwie funktioniert hab ich das Gefühl ich stecke noch voll am Anfang fest. 🙂

4. Marcel sagt:

   26. August 2017 um 22:53:12 Uhr

   Ach so, fast vergessen. Es ist nur EINE SQL-Abfrage, da ich das Objekt immer wieder für jede Abfrage neu erzeugt hatte. Ich hab mir da wohl mal was abgeschaut aus C#.

   Allg. sollte ich noch sagen, das ich über sehr viele Jahre nur Prozedural und Mit Funktionen Programmiert hatte. Das hat mich sehr sehr viele Jahre ( über 25 ) geprägt. Ich lernen zwar gut das „Wie“ bei OOP aber mir fehlt oft das „Warum“

5. Stefan Macke sagt:

   27. August 2017 um 8:15:39 Uhr

   Version 2 würde ich bevorzugen. DB-Objekt einmal erstellen (und dann z.B. im Test durch ein Mock-Objekt ersetzen) und SQL bei jeder Abfrage mitgeben. Wenn es immer derselbe String ist, kannst du den ja in der Worker-Klasse als Attribut/Konstante ablegen. Aber auch das ist eigentlich doof. Warum muss deine Worker-Klasse SQL zusammenbauen? Die Domäne sollte von der Datenbank gar nichts wissen. Besser:

   • Fachliches Interface HalloLeser mit Implementierung DbHalloLeser, die Methode findeAlleHallos() anbietet.
   • Nur DbHalloLeser enthält SQL und DB-Kram.
   • Worker bekommt den rein fachlichen HalloLeser im Konstruktor rein -> im Test einen Mock.
   • Worker ruft $leser->findeAlleHallos() auf ohne zu wissen, dass das gegen die Datenbank geht.

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

Here is some inline `code`.