mehrfachvererbung - extends - oder im Konstruktor?

[Kropff]

Ein DP (Entwurfsmuster) ist ein Plan, welchen man vor dem Programmieren erstellt, um die assoziationen verschiedenen Klassen, Objekte etc. zu definieren.

Nein, das nennt sich Modellierung oder Softwaredesign und ist eine ganz andere Geschichte.

Ein Design Pattern hilft mir jedoch eigentlich nicht dabei, objekte, klassen etc. voneinander abhängig zu machen.

Nein, es zeigt dir nur eine Lösung für gängige Probleme.

Warum für eine kleine Ausgabe ein solcher Aufwand gemacht wird. Das ist gigantisch.

Das sieht auf den ersten Blick so aus. Es liegt aber daran, dass du DP noch nicht richtig verstanden hast.

Wenn du dich wirklich damit auseinandersetzen willst, so empfehle ich dir diese Buch. Ist wirklich klasse und jeden Cent wert!

Ansonsten darfst du nicht verzweifeln, der Weg ist steinig und hart, aber mit dem entsprechenden Einsatzwillen kommt das im Laufe der Zeit.

Peter

PS: Ich weiß nicht wie dein Originalcode aussieht, aber du solltest bei Methoden auch mit Sichtbarkeitsstufen arbeiten. Und falls du es noch nicht kennst, schau dir ggf. das bei mir mal an.

[phpMorpheus2]

Spitze.
Danke Kropff

Ich lieeebe Herausvorderungen.
Darum liebe ich auch das Programmieren so sehr
Es tötet deinen letzten Nerv ab, aber wenn man es dann endlich geschafft und verstanden hat, macht es alles wieder wett

[unset]

HeHe,
aber nur so kann ich es lernen.

Wenn ich immer einer vorstukturierten Linie folge, dann kann ich zwar ein Projekt sauber und schnell verwirklichen, jedoch möchte ich es ja lernen.

Wieso sollte das eine das andere ausschließen?

Das Rad jedes mal neu erfinden zu wollen ist eine Eigenschaft, die dich nicht als besonders guten Entwickler dastehen lässt. Man muss das Rad ja nicht neu erfinden, um es zu verstehen.

Sicherlich, man darf sich nich festfressen und schon gar nicht darf man stets auf ausgetrampelten Pfaden wandeln, aber –*mit Verlaub –*ich glaube nicht, dass (schon) du die Erfahrung hast, um den dritten vor dem zweiten Schritt machen zu können.

[phpMorpheus2]

Wieso sollte das eine das andere ausschließen?

Das Rad jedes mal neu erfinden zu wollen ist eine Eigenschaft, die dich nicht als besonders guten Entwickler dastehen lässt. Man muss das Rad ja nicht neu erfinden, um es zu verstehen.

Sicherlich, man darf sich nich festfressen und schon gar nicht darf man stets auf ausgetrampelten Pfaden wandeln, aber –*mit Verlaub –*ich glaube nicht, dass (schon) du die Erfahrung hast, um den dritten vor dem zweiten Schritt machen zu können.

Was heißt, nicht als guten Programmierer dastehen zu lassen?
Natürlich wird später, wenn ich vieles gelernt habe, anders gehandelt.
Im "moment" jedoch meinte ich, erfinde ich das Rad lieber ein paar mal neu, meinetwegen mit Fehlschlägen, einfach um zu lernen.

Ich kann auch ein Projekt studieren, anschaun und es verstehen.
Aber es frisst sich nicht so fest, wie, alswenn ich es selber schreibe.
So kann ich potenzielle Fehlerquellen und andere Gedankengänge schon ausschließen und habe davon mehr denke ich.

Klar, wie gesagt. Später ist das was anderes.

Ist wie mit Vokabeln lernen.
Ich kann sie ruhig lesen und verstehen.
Aber es brennt sich nicht so fest als wenn ich sie mehrmals schreiben würde und dabei fehler mache.
So lerne ich es besser und verstehe es auch besser.

Jedem das seine. Und mir das meiste
(Kleiner Witz am Rande)

Danke für Eure kommentare.
Das hilft mir sehr weiter.

[combie]

Naja, in den Design Pattern stecken ca. 30 Jahre OOP Erfahrung.
Sie sind sozusagen die Essenz des Ganzen. Mit PHP hat das erstmal wenig zu tun. Was du hier lernst kannst du auf alle modernen Sprachen übertragen. Also viel damit üben. Dann kristallisiert sich sicherlich langsam heraus, dass die Brüder doch schon gute Arbeit geleistet haben.

[onemorenerd]

Zu deinem Bild von weiter oben: Steckt da nicht schon ein Pattern drin, MVC? index.php ist der Controller, profil.php eine Action/View und class.user.php ein Model?
Wenn das so ist, sollte class.user.php nicht direkt irgendwelche Fehler ausgeben.
PHP: Ausnahmebehandlung - Manual

[phpMorpheus2]

Zu deinem Bild von weiter oben: Steckt da nicht schon ein Pattern drin, MVC? index.php ist der Controller, profil.php eine Action/View und class.user.php ein Model?
Wenn das so ist, sollte class.user.php nicht direkt irgendwelche Fehler ausgeben.
PHP: Ausnahmebehandlung - Manual

Ja. Aber wenn in der Action/View jeweils eine Modelanfrage ausgegeben wird, so müsste ich jede Abfrage validieren, ob ein Fehler vorhanden ist.
Wenn ja, dann anzeigen.

Und das würde den Rahmen sprengen, weil die Action ja auch gleichzeitig das View ist und ich sonst in mitten von HTML die ganze Zeit php abfrage habe.

Beispiel:
Die profil.php läd eine neue user instanz (class.user.php) . Aus dieser Instanz werden nach und nach Infos abgeholt.

In der class.user.php wird bei einem fehler die Fehlermeldung in einer instanz von class.caution.php gesammelt.

Wenn ein Fehler auftritt, würde die profil.php die instanz caution abfragen und die Fehler ausgeben.

Doch diese Abfrage müsste ich dann überall machen.
das würde z.B: so aussehen:

Emailadresse: ".$user->get_detail(email)." 

Ist jedoch in dieser Abfrage ein Fehler,
wo soll ich ihn ausgeben?
Am besten, ich frage am Anfang der profil.php die Fehler ab und bei fund, blende ich nurnoch die Fehlermeldung ein.

Jedoch müsste ich dann z.B. so agieren:

$user = new user(17);
$email = $user->get_detail(email);
$irgendwas= $user->get_detail(irgendwas);
$keineahnung = $user->get_detail(keineahnung);

if($user->error->check() == true) {
 $user->error->show();
} else {

Emailadresse: $email ;
// usw.
} 

?!?

[onemorenerd]

Ja. Aber wenn in der Action/View jeweils eine Modelanfrage ausgegeben wird

In einer Action sollte gar nichts ausgegeben werden. Nur Daten aufbereitet und in den View gepumpt. Im View wird ausgegeben.

Tritt bei der Datenaufbereitung ein Fehler auf, kann die Action darauf reagieren (z.B. anderen View laden oder Fehlermeldung in den View pumpen).

// in der Action
try {
    $this->addToView($user->toTemplateData($this->getViewName()));
} catch (Exception $e) {
    $this->setView('error');
} 

// in der Klasse User
public function toTemplateData($viewName) {
    $data = array(
        'uid' => $this->uid,
        'name' => $this->name,
    );
    switch ($viewName) {
        case 'profile':
            if (empty($this->email)) {
                throw new UndefinedPropertyException('email is not set');
            }
            $data['email'] = $this->email;
            break;
    }
} 

<?php // im "profile" View ?>
Email: <?php print $user['email']; ?>

Ein View darf sich niemals Daten ziehen. Denn tritt dabei ein Fehler auf, hat er keine Chance ihn zu behandeln. Abgesehen davon veträgt sich das nicht mit Caching.


PS: Der Code ist nicht das Gelbe vom Ei. Nur ein Beispiel.

[Kropff]

PS: Der Code ist nicht das Gelbe vom Ei. Nur ein Beispiel.

OffTopic:

---

Er lernt ja noch

---

Peter

[phpMorpheus2]

In einer Action sollte gar nichts ausgegeben werden. Nur Daten aufbereitet und in den View gepumpt. Im View wird ausgegeben.

Tritt bei der Datenaufbereitung ein Fehler auf, kann die Action darauf reagieren (z.B. anderen View laden oder Fehlermeldung in den View pumpen).

// in der Action
try {
    $this->addToView($user->toTemplateData($this->getViewName()));
} catch (Exception $e) {
    $this->setView('error');
} 

// in der Klasse User
public function toTemplateData($viewName) {
    $data = array(
        'uid' => $this->uid,
        'name' => $this->name,
    );
    switch ($viewName) {
        case 'profile':
            if (empty($this->email)) {
                throw new UndefinedPropertyException('email is not set');
            }
            $data['email'] = $this->email;
            break;
    }
} 

<?php // im "profile" View ?>
Email: <?php print $user['email']; ?>

Ein View darf sich niemals Daten ziehen. Denn tritt dabei ein Fehler auf, hat er keine Chance ihn zu behandeln. Abgesehen davon veträgt sich das nicht mit Caching.


PS: Der Code ist nicht das Gelbe vom Ei. Nur ein Beispiel.

Die Action/View ist doch ein und die selbe Datei. Zumindest bei mir.
Also so!!?:
Controller -> View -> Action -> Model
index.php -> profil -> action.profil -> class.profil

Also fehlt mir also noch ein Zwischenschritt..

Ich arbeite nicht mit Exceptions.
Ich lasse die Fehlermeldungen über eine Klasse laufen, welche später abgefragt wird in der action um das view auszuwählen.

Jedoch wie nenne ich die view?
Ich habe die index.php, welche html und auch einige php assoziationen beinhaltet, wie z.B. content prüfen etc.

Dann kommt bei mir halt direkt die view, welche die action beinhaltet (profil.php) und die action in der profl.php holt sich daten aus dem Model (die klassen).

Wie nennt man so eine Datei am besten? Also die Action Datei!?
index.php -> profil.php -> action.profil.php -> class.profil.php ?!?

PostScriptum: Warum nutzt du Exceptions?
Da sind doch keinerlei AUsnahmefehlerbehandlungen in deinem Beispiel, sondern nur "normale" Fehlerabfragen welche du in exception Form validierst.
Das sollte man doch nicht machen !?
Soll doch sehr viel performance fressen..



PS2: Ich hatte mich an diese Form gehalten, welche mir keinen Anlass zu einer weiteren, seperaten "action-datei" neben der view-datei gab...

[unset]

Action(s) befinden sich idR auch im Controller und sind keine seperaten Dateien.

Und Exceptions haben erstmal nur begrenzt was mit Fehlern zu tun, sondern stellen schlicht und ergreifend eine möglichkeit zur Verfügung, aus dem Programmfluss heraus Ausnahmen behandeln zu können. Hast du zum Beispiel eien Codeblock von sagen wir einfach mal 20 Zeilen, in dem mit verschiedenen Objekten agiert wird und in einem tritt ein Problem auf, so kann dieser eine Exception schmeißen, ohne dass du irgendwelche Rückgaben ständig prüfen musst, und die geworfene Exception fangen –*wenn du das vorgesehen hast. Ansonsten kommt schlicht ein PHP-Fehler. Und Performance "fressen" Exceptions nur im "Wurf"-Fall. Das ist aber zu vernachlässigen. Exceptions liefern auch mehr Informationen als ein "false". Und da sind wir wieder an dem Punkt, den ich bereits bemäkelt habe: Du fragst irgendwo Fehler ab und reagierst darauf entsprechend und das alles mit einem Konstrukt, das schon längst da ist: Exceptions ;-)

Ein Fluent Interface wäre ohne Exceptions zum Beispiel gar nicht wirklich möglich.

[phpMorpheus2]

Ich finde das Jacke wie Hose.
Kommt aufs selbe raus.
Wo soll da ein super Vorteil drin liegen?

Klar, ich brauche nichts abfangen,
aber der Code läuft nach dem fangen der Exception weiter.
Also muss ich doch wieder irgendwas zurückgeben um zu sagen,
dass das script nen fehler geworfen hat

EDIT:
Außerdem würde mit Exceptions sogar klassen Fehler ausgeben, weil sie kein false mehr zurücksenden,
sondern einfach ne Exception werfen und dabei ne Meldung geben.
Ich habe dann ja schlecht mehr die Möglichkeit, eine Meldung später zu geben.
Und klassen "sollten" doch nichts direkt ausgeben...

try {
        if (1 == 1) {
            echo "1 ist 1";
        } else {
            throw new Exception("<p>Fehler 1");
        }

        if (2 == 5) {
            echo "2 ist 2";
        } else {
            throw new Exception("<p>Fehler 2");
        }
    } catch (Exception $e) {
        echo $e->getMessage();
    }

    echo "<p>Weiter gehts...";

    // Oder aber
    if (1 == 1) {
        echo "<p>1 ist 1";
    } else {
        echo "<p>Fehler 1";
        return false;
    }

    if (2 == 5) {
        echo "<p>2 ist 2";
    } else {
        echo "<p>Fehler 2";
        return false;
    } 

[unset]

Ich finde das Jacke wie Hose.
Kommt aufs selbe raus.
Wo soll da ein super Vorteil drin liegen?

Ich habe in meinem letzten Post eine Reihe Vorteile beispielhaft aufgeführt.

Klar, ich brauche nichts abfangen,
aber der Code läuft nach dem fangen der Exception weiter.
Also muss ich doch wieder irgendwas zurückgeben um zu sagen,
dass das script nen fehler geworfen hat

Ich habe nicht gesagt, du brauchst nichts abzufangen, ich habe gesagt, dass du nicht jeden Schritt manuell prüfen musst, ob er geklappt hat. Kleines Beispiel:

// blödsinn
$success = $item->setSomeState('something');
if($success) {
    $success = $anotherItem->setAnyState($item->getSomeState('something'));
    if($success) {
        // erfolgsmeldung an den benutzer
    } else {
        // die selbe routine wie unten. nebenbei duplicate code anti pattern
    }
} else {
    // irgend eine fehler routine
}

// besser
try {
    $item->setSomeState('something');
    $anotherItem->setAnyState($item->getSomeState('something'));
} catch(Exception $e) {
    // fehlerbehandlung. Einmal
} 

Hier kann –*irgendwo innerhalb des Codes der "setSomeState", "setAnyState" oder "getSomeState" Methoden eine Exception geworfen werden; aus welchen Gründen auch immer. Über den try catch Block fange ich diese ab. Mache ich das nicht, dann gibt es einen PHP-Fehler.

EDIT:
Außerdem würde mit Exceptions sogar klassen Fehler ausgeben, weil sie kein false mehr zurücksenden,
sondern einfach ne Exception werfen und dabei ne Meldung geben.
Ich habe dann ja schlecht mehr die Möglichkeit, eine Meldung später zu geben.
Und klassen "sollten" doch nichts direkt ausgeben...

Eine Exception gibt nichts aus, wenn sie gefangen wird und man das nicht explizit veranlasst. Wenn sie nicht gefangen wird, wird nur gesagt, dass sie geworfen wurde –*und sie nicht zu fangen ist schon mal ein Programmierfehler an sich. Und noch einmal: Eine Exception muss erst einmal keinen Fehler darstellen. Dazu einfach mal ein Artikel von mir: Re: Wann verwende ich Exceptions | Der PHP Hacker — Noch ein PHP Blog

try {
        if (1 == 1) {
            echo "1 ist 1";
        } else {
            throw new Exception("<p>Fehler 1");
        }

        if (2 == 5) {
            echo "2 ist 2";
        } else {
            throw new Exception("<p>Fehler 2");
        }
    } catch (Exception $e) {
        echo $e->getMessage();
    }

    echo "<p>Weiter gehts...";

    // Oder aber
    if (1 == 1) {
        echo "<p>1 ist 1";
    } else {
        echo "<p>Fehler 1";
        return false;
    }

    if (2 == 5) {
        echo "<p>2 ist 2";
    } else {
        echo "<p>Fehler 2";
        return false;
    } 

Der Code ist natürlich quatsch, da du eine Exception erwartest, und im Falle eine geworfenen noch eine wirfst (das ist zwar ein denkbares Szenario, aber nicht mit dem Code). Das zeigt mir nebenbei auch wieder, dass du immer noch nicht meinem Rat nachgekommen bist, dich endlich in die Materie einzulesen und immer noch damit weiter machst, zu überfliegen, dir was zusammen zu reimen und uns deine Wirren Gedanken aufräumen lässt.

[onemorenerd]

OffTopic:

---

Er lernt ja noch

---

Peter

Ich meinte meinen Code.

@phpMorpheus2: Es gibt keinen zwingenden Zusammenhang zwischen Design Patterns und der Aufteilung des Codes in Dateien. Du kannst eine komplette Applikation in einer einzigen Datei haben und dennoch dutzende Pattern benutzen. Du kannst aber auch eine Komponente, z.B. einen Controller über etliche Dateien verteilen.

PostScriptum: Warum nutzt du Exceptions?
Da sind doch keinerlei AUsnahmefehlerbehandlungen in deinem Beispiel, sondern nur "normale" Fehlerabfragen welche du in exception Form validierst.

Ach ja? Also in 99% meiner Applikationen gilt ein Userobjekt ohne Emailadresse als kaputt. Email ist Pflicht bei der Registrierung und kann nicht gelöscht werden, nur geändert. Insofern ist es sehr wohl eine Ausnahme, wenn keine Email vorhanden ist. Darf eigentlich nie passieren.

Über Performance braucht man sich bei Exceptions eigentlich nie Gedanken machen. Es wird ja immer nur eine geworfen!
Üblicherweise wird sie nah bei der Quelle gefangen und deeskaliert - in diesem Fall geht der Programmablauf meist ungestört weiter - oder sie bubbelt bis ganz nach oben zu einem zentralen Catcher, der als letzte Instanz vorm User steht, damit der keine PHP-Fehlermeldungen zu sehen bekommt. So ein zentraler Catcher kann dann aber auch nichts mehr deeskalieren. Er leitet meist nur auf eine Fehlerseite um.

[phpMorpheus2]

Was ist denn an dem Codebeispiel so falsch und zusammengereimt?