Ressourcenschonung in PHP Objekten

[gernea]

Hallo,

verständnissfrage, ist es grundsätzlich schonender in einer beliebigen Class eine bereits deklarierte globale Class über ( global $var ), zuzuladen oder diese neu zu laden ( $var = new xyz; )? Meinungen?

Grüße

[h3ll]

Diese Frage ergibt keinen Sinn.

1. global ist generell böse und zu vermeiden.

2. Brauchst du jedesmal ein anderes Objekt, dann new.

3. Brauchst du immer das selbe Objekt, dann einmalig erstellen und an die jeweilige Funktion, die sie benötigt, übergeben.

Die Antwort ergibt sich also aus der Anforderung (die du nicht genannt hast).

[gernea]

Auf den ersten Blick sinvoller Zusammenhang, vieleicht eher eine Frage der Angehensweise.

Wenn du zu Beginn deines Scriptes eine class mit function's gerufen hast die z.B. parameter sammelt oder den nutzer klassifiziert, abgelegt z.B. in der globalen $save. Wenn ich nun in späteren zusammenhängen Zugriff auf diese parameter benötige ist es doch am einfachsten diese global zuzuladen, als diese durch jede function zu schleifen bzw. die daten durch neuanlage erneut zu sammeln... Andere idee hierzu?

[combie]

Auch in der OOP gibt es "statische" Dinge. Ein "global" ist da nun wirklich nicht nötig. Auch ist es böse, wie mein Vorredner schon sagte.

die daten durch neuanlage erneut zu sammeln...

Das ist auch böse.

Andere idee hierzu?

Bei den "PHP OOP Design Pattern" wirst du sicherlich fündig. Wobei ich dir aber direkt vom "Singleton Design Pattern" abraten möchte. Es hat, mehr oder weniger, die gleiche Neigung unerwünschte Seiteneffekte zu fördern, wie "global".

[h3ll]

Wenn du zu Beginn deines Scriptes eine class mit function's gerufen hast die z.B. parameter sammelt oder den nutzer klassifiziert, abgelegt z.B. in der globalen $save.

global ist böse. Habe ich bereits gesagt und hat bei der OOP-Programmierung nichts verloren.

Wenn ich nun in späteren zusammenhängen Zugriff auf diese parameter benötige ist es doch am einfachsten diese global zuzuladen, als diese durch jede function zu schleifen bzw. die daten durch neuanlage erneut zu sammeln...

Dem ersten Anschein nach vielleicht. Aber später wirst du dich einmal hassen dafür.

Andere idee hierzu?

Dependency Injection

[gernea]

Klingt vernünftig, habe ein kleines Beispiel gebaut, hintergund ist das ich z.B. die class log an verschiedenen stellen mit daten versorgen / beziehen möchte, geht das anders besser?

class Log
    {
    public $book;
    function __construct($str)
        {
        $this->SetLog($str);
        }
    
    public function GetLog()
        {
        echo $this->book;
        }
        
    public function SetLog($str)
        {
        $this->book .= $str."<br>";
        }
    }

class Wohnung
    {
    private $Street;
    protected function SetStreet($str)
        {
        $this->Street = $str;
        }
    
    protected function GetStreet()
        {
        return $this->Street;
        }
    }

class Zimmer extends Wohnung
    {
    function __construct(Log $log)
        {
        $this->log = $log;
        }
    
    public function Einzug()
        {
        Wohnung::SetStreet('Humboldstr');
        $this->log->SetLog('Set a Street');
        }
    
    public function Visitenkarte()
        {
        echo $this->GetStreet();
        $this->log->SetLog('Get a Street');
        }
    
    }

$log = new Log('Start');
    
$wohnen = new Zimmer($log);
$wohnen->Einzug();
$wohnen->Visitenkarte();

$log->GetLog(); 

[mermshaus]

Hm, ich frage mich, warum du da die Vererbung drin hast, also worum es dir mit diesem Beispiel genau geht?

Die Art und Weise der Übergabe des Loggers für sich betrachtet, also die Zuweisung im Konstruktor, ist so aber durchaus sinnvoll, ja.

[h3ll]

geht das anders besser?

http://flow3.typo3.org/documentation...ogramming.html

[gernea]

Also wenn wir das zusammenfassen, sollte Ziel sein alle Var's über die Abläufe zuzuladen und ergebnisse zu returen, keine Globalen.

1.) Wie haltet Ihr es mit $_POST, $_GET und $_SESSION, ist es auch sinvoll diese nur nach bedarf zuzuladen ganz/einzelteile oder globaler Abgriff in der Class?

2.) Schleift Ihr den $MYSQLI nach erfolgreicher Connection auch durch den ablauf zu jedem Punkt an dem dieser benötigt wird?

[h3ll]

1.) Wie haltet Ihr es mit $_POST, $_GET und $_SESSION, ist es auch sinvoll diese nur nach bedarf zuzuladen ganz/einzelteile oder globaler Abgriff in der Class?

Schau dir mal das Zend Framework als Beispiel an.

GET- und POST-Parameter stehen hier im Zend_Request. Und die Session wird über Zend_Session abgehandelt.

Globaler Zugriff ist zu vermeiden, weil es sonst die Testbarkeit und Modularität behindert.

2.) Schleift Ihr den $MYSQLI nach erfolgreicher Connection auch durch den ablauf zu jedem Punkt an dem dieser benötigt wird?

Ja. Aber so viele Stellen sind das nicht. Es sollte nur die Persistenzschicht Zugriff auf die Datenbankverbindung haben. Die Domänen- und Präsentationsschicht haben damit nix am Hut.

[mermshaus]

Ja. Aber so viele Stellen sind das nicht. Es sollte nur die Persistenzschicht Zugriff auf die Datenbankverbindung haben. Die Domänen- und Präsentationsschicht haben damit nix am Hut.

Ja. „Durchschleifen“ klingt immer so, als würde man irgendeinen Ballast, der allgemein absolut nichts mit der Teilkomponente zu tun hat, über 20 geschachtelte Methodenaufrufe weiterreichen.

Ich glaube, das ist mehr ein latentes Empfinden als ein tatsächliches Problem. Oder der Fehler liegt eben bereits im Design, auch wenn das jetzt natürlich einfach gesagt ist.

Die Vorstellung sollte eher so gehen: Wenn ich ein Objekt irgendwo innerhalb einer Teilkomponente benötige, hängt die gesamte Teilkomponente von diesem Objekt ab.[1]

Global state ist prinzipiell zu vermeiden (dazu zählen auch Singletons, Registries, für mich auch (statische) Klassenvariablen). Der new-Operator sollte nach Möglichkeit nur in dedizierten Fabrikmethoden auftauchen.

So was ist aber glaube ich nur sinnvoll an echten Beispielen zu diskutieren. Falls da jemand was hat, bei dem etwa das Problem des Durchschleifens besteht, sehr gerne.



1: Meiner Erfahrung nach hat Code da die Angewohnheit, sich selbst zu organisieren. Wenn dir bei der Programmierung irgendwas unsauber vorkommt, ist es zumeist auch unsauber. Bei mir wird das meist darin offensichtlich, dass ein Objekt etwas kann, auf das ich an einer Stelle, an der ich das Objekt nutze, keinen Zugriff gestatten will. Das ist in der Regel ein Anzeichen dafür, dass mein Objekt zu viel tut und ich ein weiteres Objekt einführen sollte, um Teilfunktionalität zu kapseln, oder dass ich ein Objekt von zu weit oben in der Objekthierarchie übergeben habe. Wenn ich nur Zugriff auf den Logger haben möchte, brauche ich etwa nicht die gesamte Anwendung zu übergeben (Gesetz von Demeter).

[unset]

"Statische" Klassenvariablen (eigentlich meine ich Konstanten) braucht man alleine deswegen schon, um "magic numbers" zu vermeiden. Status-Codes, bestimmte Zustände und andere Dinge, die numerisch abgebildet werden, brauchen zwangsläufig eine "menschenlesbare" Repräsentation. Ansonsten stimme ich dir aber weitestgehend zu.

[gernea]

static?

Somit dann die Frage in welchen situationen man eher auf static functions zurückgreift, rein von dem was an code im netz zu finden ist werden abwicklungen von sessions und mysql oft über static gelöst, mal abesehen davon das es keine $this deklaration in static gibt?

Ergebnisse wärn hier die gleichen... Argumente?

class var1
    {
    public static $val = array();
    
    public static function get($key)
        {
        return self::$val[$key];
        }
    public static function set($key, $val)
        {
        self::$val[$key] = $val;
        }    
    }

class var2
    {
    public $val = array();
    
    public function get($key)
        {
        return $this->val[$key];
        }
    public function set($key, $val)
        {
        $this->val[$key] = $val;
        }    
    }

var1::set("Auto", "Ford");
echo var1::get("Auto");

$var2 = new var2();
$var2->set("Auto", "Ford");
echo $var2->get("Auto"); 

[mermshaus]

So eine statische Klasse ist wenig mehr als einige globale Variablen und Funktionen, die in einem Namespace (dem Klassennamen) zusammengefasst werden.

Es existieren keine Instanzen der Klasse. Wenn du mich fragst, ist das eigentlich auch keine Objektorientierung.