Frage zu PHP 5 OOP

[MaxPayne]

Das zeigt, dass du meine Frage nicht verstanden hast. Die Datenkapselung durch Klassen und deren Kinder, wird von mir auch in PHP befürwortet - ich würde selbst nicht mehr ohne auskommen. Ich frage mich nur, ob es unbedingt notwendig gewesen wäre, die Visibility-Optionen zu erzwingen - dafür hat sie in einer Skriptsprache zu wenig Nutzen - höchstens symbolischen Charakter, wie im diesem Thread ja bisher erörtert würde.

Eine nützliche neue Implementierung ist zum Beispiel die Möglichkeit Objekte zu klonen.

[beebob]

hi,
ich habe hier mal die antworten nur so überflogen, hoffe also, ich beantworte jetzt nichts doppelt...

die deklaration von auf private gesetzten klassen, methoden und variablen hat vor allem was mit dem erhalt der konsistenz einer klasse und damit auch dem instanziierten objekt zu tun.

es geht schlicht und ergreifend darum, dass du, wenn du eine klasse entwickelst, diese idealerweise derart zu gestalten hast, dass sie auch die funktionlität bereitstellt, die du für sie gedacht hast; und nichts mehr.

das bedeutet, sichere deine klassen derart ab, dass par definition gar keine, oder möglichst wenige seiteneffekte bei der nutzung auftreten können.

ein hilfsmittel dabei ist eben die möglichkeit des private setzens.

aber: private function blabla() allein macht noch nicht glücklich.

wichtig ist auch, dass du eigene exceptions definierst und du diese 'so weit wie möglich' nach oben durchreichst, um ein stabileres laufzeitverhalten deines skriptes zu ermöglichen. also nicht mehr kreuz und quer im code verteilte error messages, sondern durch try/catch abgefangene exceptions verwerten (wie gesagt, diese hochreichen 'bis zum anschlag').

hoffe, das hat dir ein paar fragen beantwortet.

gruss,
beebob

[pekka]

Für mich dienen Dinge wie Visibility-Optionen hauptsächlich zum Schutz vor Schludrigkeit beim Programmieren unter Zeitdruck. Also nach dem Szenario: Man arbeitet im Team an einem Projekt. Das Objekt $bmw (Um im Auto-Beispiel zu bleiben) soll auf 100 km/h beschleunigt werden. Der Prakti, der dafür zuständig ist, möchte schnell nach Hause weil die Sonne scheint. Daher neigt er zu

$bmw->geschwindigkeit = 100;

Wenn man die Variable direkt setzt, wird aber der Benzinverbrauch nicht hochgesetzt und das Crashrisiko nicht neu berechnet. In der Doku steht zwar, daß man nur auto::beschleunigen(), ::verlangsamen() und ::bremsen() benutzen soll - die liest sich unser hypothetischer Praktikant aber nur flüchtig durch, und zuhause wartet ein kalter Caipirinha. Wenn $geschwindigkeit aber Private deklariert ist, wird er gezwungen, sich an die dafür vorgesehenen Funktionen zu halten.

Na gut, ein etwas hinkender Vergleich. Aber ihr versteht was ich sagen will

[MaxPayne]

Original geschrieben von pekka
Na gut, ein etwas hinkender Vergleich. Aber ihr versteht was ich sagen will

Jap. Hast mich überzeugt.

[GriZZ]

Original geschrieben von beebob
wichtig ist auch, dass du eigene exceptions definierst und du diese 'so weit wie möglich' nach oben durchreichst, um ein stabileres laufzeitverhalten deines skriptes zu ermöglichen. also nicht mehr kreuz und quer im code verteilte error messages, sondern durch try/catch abgefangene exceptions verwerten (wie gesagt, diese hochreichen 'bis zum anschlag').

gruss,
beebob [/B]

Hi,

wo wir gerade bei den Exceptions sind: Wie verwende ich sie denn am besten ? Ich habe 3 meiner Klassen in php5 neu geschrieben. Bsp. class DB für mysql. immer wenn nun eine abbruch bedingung kommt werfe ich mit throw eine neue Exception in meine DBException class.

z.B mit:

throw new DBException( __METHOD__ . ' failed: ' . mysql_error() . ' ' . mysql_errno() );
throw new DBException( __METHOD__ . ' failed: Empty Table ' ); 

soweit ich das getstet habe geht es auch, aber nur wenn ich meine gesammten Code dann in try{} einfasse.

try{
        $DB = new DB();
        $DB->set_connect( 'localhost',3306,'user','pass');
        $DB->connect();
// ... Mehr Code
$DB->close();
}
catch( DBException $DBE ){
        echo $DBE->getMessage();
    } 

also wie verwende ich das nun am besten ? ich mochte ja nicht jede seite für jede Klasse einen try catch block angeben?

Hier nochmal meine DBException

class DBException extends Exception {

        public function __construct( $message ){
            parent::__construct( $message );
        }
    } 

Wurde es nicht auch sinn machen ein static array() für alle messages zu machen um die dann gesammelt auszugeben ?

Gruß GriZZ

[beebob]

@grizz:

naja, ich entnehme mal deinem code + aussage, dass du der ganzen DB klasse eine einzige exception zugeordnet hast.

wenn du das getan hast, dann musst du halt um jede zeile, wo ein aufruf einer methode dieser klasse stattfindet, ein try/catch block packen.

darum solltest du nicht eine einzige generelle db exception implementieren, sondern halt nur da, wo es sinn macht.

z.b.

public function  set_connect($str, $int, $str, $str) throws DBSetConnectionException
{
    //.....
} 

das bedeutet dann, dass du einen try/catch block dann nur um den aufruf dieser methode 'wickeln' musst.

mit anderen worten, du solltest deine exceptions feiner granulieren.

gruss,
beebob

[GriZZ]

Jo, da hast Du wohl recht, es fehlt sowas wie ein catch_all, bleibt einem wohl nichts überig als bei einem error handler zu bleiben. ich dachte man könnte es damit schön global lösen. aber seinen ganzen code von 3 oder 4 trys zu umschliessen kann es ja auch nicht sein.

Ich hab mal ein wenig probiert die ganzen Errors einzufangen und dann in einer eigenen function mit throw rauszuwerfen, so kann ich meine templates sehr schön füllen. ob es was nützt oder nicht, hier mal der bespielcode. vielleicht kann es ja jemand gebrauchen oder es ist ein denk ansatz.

PHP5:

<?

    class MyException extends Exception{

        public static $ErrorCounter = 0;
        public static $ErrorMessages = array();

        public function __construct( $exception ){
            parent::__construct( $exception );
            $this->$ErrorCounter = self::$ErrorCounter++;
        }
    }

    Class ErrorHandler {

        public function error( $exception, $method = '', $line = NULL, $throw = TRUE, $exit = FALSE ){

            try{
                if ( $throw === TRUE ){
                    throw new MyException( $exception );
                }
            }
            catch( MyException $E ){
                MyException::$ErrorMessages[MyException::$ErrorCounter]['message'] = $E->getMessage();
                MyException::$ErrorMessages[MyException::$ErrorCounter]['method']  = $method;
                MyException::$ErrorMessages[MyException::$ErrorCounter]['line']    = $line;
                MyException::$ErrorMessages[MyException::$ErrorCounter]['file']    = $E->getFile();
            }

            if ( $exit === TRUE ){
                print_r(MyException::$ErrorMessages);
                exit;
            }
        }
    }

    Class DB {

        public function connect(){
            ErrorHandler::error("Could not connect", __METHOD__, __LINE__);
        }

        public function select_db(){
            ErrorHandler::error("Could not select DB", __METHOD__, __LINE__);
        }

        public function close(){
            ErrorHandler::error("Could not disconnect", __METHOD__, __LINE__);
        }
    }

    Class DB2 {

        public function result(){
            ErrorHandler::error("Could not result", __METHOD__, __LINE__);
        }

        public function query(){
            ErrorHandler::error("Could not query DB", __METHOD__, __LINE__);
        }

        public function free(){
            ErrorHandler::error("Could not free", __METHOD__, __LINE__);
        }
    }

    function test(){
        ErrorHandler::error("Could not test()", __METHOD__, __LINE__);
    }



    echo '<pre>';

    test();

    $DB = new DB;
    $DB->connect();
    $DB->select_db();
    $DB->close();

    $DB2 = new DB2;
    $DB2->result();
    $DB2->query();
    $DB2->free();


    echo 'Error Message Counter: ';
    print_r(MyException::$ErrorCounter);
    echo "\n";
    echo 'Error Messages Array: ';
    print_r(MyException::$ErrorMessages);
    echo '</pre>';

?>

Gruß Grizz

[MaxPayne]

Ist wunderschön eure Diskussion mal hier zu verfolgen. Leider ist die PHP-Doku an der Stelle, wo es um das neue OOP-Modell geht ziemlich unvollständig. Könnt ihr mir vielleicht mal ne Ressource in URL-Form liefern, wo ich mehr über die neue OOP-Implementierung erfahren kann?

Ist ja alles ziemlich C-ähnlich, aber alles hat man sicher auch nicht übernommen.

Danke im Voraus.

[GriZZ]

Original geschrieben von MaxPayne
Könnt ihr mir vielleicht mal ne Ressource in URL-Form liefern, wo ich mehr über die neue OOP-Implementierung erfahren kann?

Ich hab vor einiger Zeit mal ein pdf hier gefunden:
http://www.virtuelle-maschine.de/index.php?contId=13

Um einen einblick zu haben sicherlicht nicht das schlechteste. Ansonsten natürlich wie immer googlen oder das ein oder andere Buch kaufen.

Gruß GriZZ

[MaxPayne]

Danke. Google liefert derzeit nocht nichts brauchbares in Deutsch. Ist halt Mist, dass die Entwickler nicht mit der Dokumentierung hinterherkommen. Wenn man schon neue Features rausbringt, sollte wenigstens die englische Version der Doku hinsichtlich derer vollständig sein.

[markusschmitt]

2 Fragen am Rande?
Warum wurde kein Modul PHP5 hinzugefügt, das Wrapperklassen ermöglicht. Dadurch das PHP5 es ermöglicht bei Methoden und Funktionen Objektparameter auf das korrekte Objekt zu überprüfen wäre dies doch eine wunderbare Annäherung an Java und würde wesentlich schöneren Code abgeben wenn man nicht erst auf die korrekten primitiven Datentypen überprüfen müsste.

Warum wurde kein Möglichkeit geschaffen Methoden und Funktionen zu überladen wenn eine solche Objektüberprüfung besteht. Eine Abwärtskompatibilität wäre gegeben aber wenn man dies über z.B. einen Punkt in der php.ini aktivieren könnte, das wäre es doch wunderbar.

MfG Markus

[GriZZ]

Jo Hi,

PHP5 bietet vielleicht nicht den umpfang wie Java, aber er ist möglich classen zu überladen, naja zumindest so in der art. dazu gibt es die function __call. die parameter unterscheidung kann man mit func_num_args machen. in der methode __call könnte man die typen prüfen und dann vorhande methoden aufrufen.

Für Instanzvariablen bietet PHP5 __get und __set. leider war es das auch schon in dem Bereich, hoffen wir mal das Properties später noch nachgereicht werden. wenn man also nicht darauf verzichten will, muss man sich die classen selber schrieben.

Zu den Wrappern. Sicherlich eine schöne Sache, hoffe da kommt noch was, damit würde man auf jedenfall einen weiteren Schritt machen in Richtung OO. Aber viele haben ja so schon genug Probleme OO zu arbeiten. Und da PHP ja eine automatische Typkonvertierung hat, wissen viele nich tmal mit welchen datentyp sie gerade arbeiten. und bei mysql kann man den datentyp ja auch angeben :-) Wenn Du nicht drauf verzichten kannst, musst Du wohl selber welche bauen. java=>lang :-)

Es sind zumindest genug ansätze da um weiter zu machen. Hoffe wir müssen nicht auf Zend 3 warten bis einige der neuenFunktionen und Klassen kommen.

GruZZ GriZZ

[markusschmitt]

Wäre doch mal ein schönes Projekt java=>lang und java=>io (zumindest die Grundklassen) nachzubauen, na wer hat Lust?

MfG Markus

[GriZZ]

Naja, wer zuviel Zeit hat, aber einiges sollte kein Problem sein. Und wer umbedingt mit Java und PHP spielen will sollte sich die Extension dazu mal ansehen und ins Manuel blicken.

[webstar85]

Original geschrieben von markusschmitt
Wäre doch mal ein schönes Projekt java=>lang und java=>io (zumindest die Grundklassen) nachzubauen, na wer hat Lust?

MfG Markus

Gibt es bereits schon (http://www.japha.net/). Wie weit das vollständig ist, keine Ahnung. Habe das Framework noch nicht getestet, nur vor kurzen in einem anderen PHP Forum entdeckt.