__DIR__ / __FILE__ der Klasse ausgeben, in globaler, geerbter Methode?

[Forumsgast]

Hallo,

es gibt eine "Master-Class", die via "extends" in viele Anwendungsklassen verebt wird. Dort soll auch eine Methode "get_app_info()" sein, die aber Infos der Klassen ausgibt, die sie geerbt haben.

Die Anwendungsklassen werden naturgemäß in anderen Verzeichnissen und ggf. auch weiteren, anderen Umgebungen deklariert.

Unter anderem würde ich gerne das Verzeichnis oder auch den Dateinamen des Scripts, welches die Anwendungsklasse deklariert, mit der get_app_info() auslesen.

__DIR__, getcwd(), __FILE__ und auch ein eval( "return __DIR__;" ) liefern (natürlich) immer das Verzeichnis zurück, in dem die Methode deklariert ist ...

... gibt es eine elegantere Möglichkeit als diese Infos via debug_backtrace() herauszufinden?


Danke im voraus.

[Forumsgast]

Klingt nach einem ziemlichen Fehlkonzept und einer Art Gott-Klasse. Ableitungen sollten nur sehr sparsam eingesetzt werden und sind in 99% der Fälle nicht erforderlich. Wenn "viele" Klassen abgeleitet werden, ist das sehr fishy.

[Forumsgast]

Wenn man sich an ein Autoload Standard wie etwa PSR-4 hällt kann man den Pfad aus dem Klassennamen ableiten. mit get_parent_class kann man die Elternklasse abfragen und wenn sie einen Namenspace hat, weiß man dann auch in welchen ordner die Klasse liegt.

alternativ

https://www.php.net/manual/de/reflec...etfilename.php kann man dann mit get_parent_class kombinieren

EDIT: aber hellbringen hat Recht, "Master-Class" klingt nach "Gott-Class" und ist ein Antipattern.

[Forumsgast]

Verstehe nicht so 100% die Kritik ... vermutlich mangels Erfahrung/Kenntnissen.

Vererbung ist ja - ähnlich wie eingebundenen Funktionen - nach meinem Verständnis ein Mittel, um nicht "standard-code" immer und immer wieder programmieren (oder hinein-Kopieren) zu müssen? Ich habe z.B. eine bestimmte Vorgehensweise bei logging, Argumente-Vererarbeitung etc., die ich in alle meine Anwendungsklassen vererbe.

Hat m.E. (auch) den Vorteil, dass man ggf. Teile davon (oder auch das Verhalten) in einer Anwendungsklasse (ausnahmsweise) durch "überdefinieren" oder eben auch Parameter modifizieren kann.

Klar muss das dann ordentlich dokumentiert werden ...

Was mein konkrete Fragestellung angeht ist es z.B. so, dass ich eine geordnete Struktur haben möchte und sowohl für's ein- wie auch für's auslesen der Infos Methoden zur Verfügung stelle. Ändert sich dann einmal die Struktur der Daten, ist keine der Anwendungen betroffen, weil eben alles durch die Methoden gepuffert wird.

Was ist daran falsch?

[Forumsgast]

Vererbung ist ja - ähnlich wie eingebundenen Funktionen - nach meinem Verständnis ein Mittel, um nicht "standard-code" immer und immer wieder programmieren (oder hinein-Kopieren) zu müssen?

Nein, ist es nicht. Vererbung dient dazu eine Klasse zu erweitern oder zu beschränken und nicht um Funktionen wiederzuverwenden.

Ich habe z.B. eine bestimmte Vorgehensweise bei logging, Argumente-Vererarbeitung etc., die ich in alle meine Anwendungsklassen vererbe.

Das ist der falsche Ansatz. Übergib ein Logging-Objekt an die jeweilige Klasse.

Klar muss das dann ordentlich dokumentiert werden ...

Naja, ich kann auch meinen Müllsack daheim dokumentieren. Es bleibt trotzdem ein Müllsack, der entsorgt gehört. Nur weil man etwas dokumentiert, wird es nicht automatisch richtig oder erhaltenswert.

[Forumsgast]

Nein, ist es nicht. Vererbung dient dazu eine Klasse zu erweitern oder zu beschränken und nicht um Funktionen wiederzuverwenden.



Das ist der falsche Ansatz. Übergib ein Logging-Objekt an die jeweilige Klasse.



Naja, ich kann auch meinen Müllsack daheim dokumentieren. Es bleibt trotzdem ein Müllsack, der entsorgt gehört. Nur weil man etwas dokumentiert, wird es nicht automatisch richtig oder erhaltenswert.

Ganz so krass hätte ich es jetzt nicht ausgedrückt. @TE: dokumentier mal deine Klassen Hierarchie mit UML (UMLET oder so), dann siehst du genau welche Klassen was vererben und du kannst dich reorganisieren. Ansonsten wenn du die Infos z.B. fürs Logging haben willst nimm doch die magischen Methoden oder übergebe lokale Log Infos als Objekte an beliebige Orte wo du die hinhaben willst und mach dir gleich einen Konfig Eintrag wo du Einstellungen vornehmen kannst.

[Forumsgast]

Ansonsten wenn du die Infos z.B. fürs Logging haben willst nimm doch die magischen Methoden

Bitte keine magischen Methoden. Das ist der nächste große Unfug.

[Forumsgast]

Verstehe nicht so 100% die Kritik ... vermutlich mangels Erfahrung/Kenntnissen.

Vererbung ist ja - ähnlich wie eingebundenen Funktionen - nach meinem Verständnis ein Mittel, um nicht "standard-code" immer und immer wieder programmieren (oder hinein-Kopieren) zu müssen? Ich habe z.B. eine bestimmte Vorgehensweise bei logging, Argumente-Vererarbeitung etc., die ich in alle meine Anwendungsklassen vererbe.

Und jetzt versteht ihr wenigstens mein damaliges Video wieso ich extends nicht emfpehlen kann und stattdessen eher dann Traits genutzt werden soll. denn genau so denkt ein Anfänger der gerde in OOP reinkommt und ihr habt mich alle gebashed..

ich will ja nicht sagen aber da habt ihr es!!! *drop microphone*

[Forumsgast]

z.B. fürs Logging haben willst nimm doch die magischen Methoden oder übergebe lokale Log Infos als Objekte an beliebige Orte wo du die hinhaben willst und mach dir gleich einen Konfig Eintrag wo du Einstellungen vornehmen kannst.

Nein, ich habe auch ein Video erstellt wieso Magischer Code schlecht ist fürs Loggen nutzen wir einen PSR Logger und eine Implementierung wie etwa Monolog die Implementierung wird über einen DI Container konfiguriert und in eine Klasse Injeziert ohne Magie(Außer bei Autowire )

[Forumsgast]

Und jetzt versteht ihr wenigstens mein damaliges Video wieso ich extends nicht emfpehlen kann und stattdessen eher dann Traits genutzt werden soll. denn genau so denkt ein Anfänger der gerde in OOP reinkommt und ihr habt mich alle gebashed..

Wobei ich immer noch kein Freund von Traits bin. Was spricht dagegen in dem Fall den Logger im Konstruktor zu übergeben? Meistens sind die einfachsten Lösungen auch die besten. Sicher mögen Traits ihre Daseinsberechtigung haben. Aber da sehe ich eine ähnliche Gefahr wie bei der Vererbung: Zeigt man es einem Anfänger, sieht dann jedes Problem wie ein Nagel aus, für das man einen Hammer benötigt.

Meiner Ansicht nach lernt man OOP am besten, wenn man auf diese "Spielereien" vorerst verzichtet und die Basis mit den wichtigsten OOP-Pattern lernt.

[Forumsgast]

Wobei ich immer noch kein Freund von Traits bin. Was spricht dagegen in dem Fall den Logger im Konstruktor zu übergeben? Meistens sind die einfachsten Lösungen auch die besten. Sicher mögen Traits ihre Daseinsberechtigung haben. Aber da sehe ich eine ähnliche Gefahr wie bei der Vererbung: Zeigt man es einem Anfänger, sieht dann jedes Problem wie ein Nagel aus, für das man einen Hammer benötigt.

Ne Fall Logger und Trait macht nur sinn wenn du keine Lust hast setLogger jedes Mal zu schreiben,deswegen gibt es den LoggerAwareTrait von PSR aber ich meinte statt jetzt generell irgend eine Gott Klasse zu machen und alle davon abzuleiten, besser viele kleine Traits zu definieren mit diesen Funktionen und die Traits in der Klasse nutzen. Traits lassen sich wesentlich besser steuern falls sich die Basis verändert hat mit as und alias und was weiß ihc nicht was.

Logger würde ich direkt über constructor den PSR Logger injezieren und dann DI Container Autowire nutzen


Mit Traits kannst du eingetlich in PHP dann Component Entity System umsetzen.

Du hast deine Componenten mit Methoden die in einem Trait definiert sind und diese haben sogar eventuell abstrakte Methoden und dann erstellst du deine Entity und die nutzt dann die Componenten. Wird gerne in Game Engines eingesetzt, könnte man sich PHP Seitig vorstellen wenn man eine "FormBuilder Engine" bauen wollen würde

Meiner Ansicht nach lernt man OOP am besten, wenn man auf diese "Spielereien" vorerst verzichtet und die Basis mit den wichtigsten OOP-Pattern lernt.

Ja das muss erst verstanden werden, aber bis es soweit ist, gibt es einen "Hack" oder "Eselsbrücke" , kein extends nutzen sondern ein Trait. Wenn man verstanden hat wie DI Container und OOP pattern funktionieren dann Traits löschen und es richtig machen. Mit Traits wird es einfacher sein als mit Vererbung. Also schrittweise entfernen

[Forumsgast]

Ne Fall Logger und Trait macht nur sinn wenn du keine Lust hast setLogger jedes Mal zu schreiben

Deswegen hat man dann eine Dependency Injection, die sich darum kümmert.

Logger würde ich direkt über constructor den PSR Logger injezieren und dann DI Container Autowire nutzen

Also eh

[Forumsgast]

Ich will nicht undankbar sein ... aber ihr lasstr mich gerade weit hinter Euch. Ich verstehe nahrzu nichts von dem, was ihr da gerade diskutiert ...

Wobei ich das mit den Traits ebenfalls fast so sehe, und auch einiges via Traits statt extends gemacht habe ... schon, weil man via traits auf private properties zugreifen kann, was mit mehtoden aus der Vererbung nicht geht ...

Was mir jetzt noch fehlt, wäre, dass man zu einem späteren laufzeit-Zeitpunkt traits auch noch überschreiben kann (mit Wirkung in die Klassen hinein, die mit use Traits eingebunden haben) ... dann könnten sich meine Klassen nur soweit aufbauen, wie es wirklich gebraucht wird (jaja, ich weiss, es kommt nicht auf Millisekunden an und PHP ist für zeitkritische Anwendungen eh die falsche Plattform)

Gerade beim Logging wäre das sehr nett, wenn in "normaler Umgebung" kein logging gespeichert würde, aber wenn Fehler sind, das logging mit schreibt. Und zwar OHNE, dass man in den log-methoden jedesaml Zeit verliert, um mit "if" festzustellen, ob nun zu loggen ist oder nicht.

[Forumsgast]

Hallo,
es gibt eine "Master-Class", die via "extends" in viele Anwendungsklassen verebt wird. Dort soll auch eine Methode "get_app_info()" sein, die aber Infos der Klassen ausgibt, die sie geerbt haben.
.

Verpasse deiner "Master-Class" doch auch eine Methode get_app_info() die du dann in deiner "Anwendungsklasse" aufrufst. Beispiel:

class master{
  public function get_app_info(){
    return [
      "file" => __FILE__,
    ];
  }
}

class ext1 extends master{
  public function get_app_info(){
    return [
      "file" => __FILE__,
      "parent" => parent::get_app_info(),
    ];
  }
}

$ext1 = new ext1;
var_dump($ext1->get_app_info()); 

Anmerkung zu den bisherigen Beiträgen:
Hinweise zu einen möglichen Fehlkonzept sind ok. Ich sehe aber nicht das auf die eingangs gestellte Frage von jwka61 eingegangen wurde.

[Forumsgast]

Ich sehe aber nicht das auf die eingangs gestellte Frage von jwka61 eingegangen wurde.

in #3 habe ich Reflections vorgeschlagen