XHTMLforum

XHTMLforum (http://xhtmlforum.de/index.php)
-   Serveradministration und serverseitige Scripte (http://xhtmlforum.de/forumdisplay.php?f=80)
-   -   PHP, OOP und Array Übergabe (http://xhtmlforum.de/showthread.php?t=63223)

laborix 12.12.2010 15:30

PHP, OOP und Array Übergabe
 
Hallo miteinander,

eine theoretische Frage, die ich noch nicht verstehe, die mich aber sehr interessiert.

Die Klasse:
Code:

class ConfigPanel {

  public function readconfigfile(array $readconfig) {

  }

  public function showconfigfile(array $showconfig) {

  }

  public function writeconfigfile(array $writeconfig) {

  }

}

Der Aufruf in configpanel.php:
Code:

require_once("class.contactconfig.php");

$debugarray = array();
$debugconfigpanel = new ConfigPanel();
$debugarray = $debugconfigpanel->readconfigfile($debugarray);
$debugarray = $debugconfigpanel->showconfigfile($debugarray);
$debugarray = $debugconfigpanel->writeconfigfile($debugarray);

Zur Frage:
Kann ich für alle drei Funktionen innerhalb der Klasse den gleichen Array Namen angeben?
Code:

class ConfigPanel {

  public function readconfigfile(array $config) {

  }

  public function showconfigfile(array $config) {

  }

  public function writeconfigfile(array $config) {

  }

}

Weiss das einer von euch und kann mir das irgendwie verständlich machen ob das geht oder nicht?

Hinweis:
Zur Zeit arbeite ich mit drei verschiedenen Array Namen und es funktioniert. Ich bekomme auch keinen Fehler oder Hinweis, wenn ich mit
Code:

error_reporting (E_ALL | E_STRICT);
arbeite. Ich stecke hier noch etwas in den Anfängen :roll:

Danke

stravid 12.12.2010 23:27

Ja das geht.

Du kannst ihnen den gleichen Namen geben da es Funktionsparameter sind und sie deswegen nichts miteinander zu tun haben.

Praktikant 13.12.2010 01:45

Funktionsparameter sind nur in den Funktionen verfügbar in denen sie definiert sind. So sind deine 3 Arrays auch nur in den Funktionen verfügbar, sie wissen garnicht dass in einer anderen Funktion eine Variable gleichen Namens existiert.

Würdest du jedoch eine Klassenvariable daraus machen ($this->array), dann wäre diese in jeder Funktion das selbe Array. Ändert dann eine Funktion etwas am Inhalt, z.B. durch hinzufügen oder löschen, so wissen alle andere Funktionen gleich von der Änderung und arbeiten mit dem gleichen Datenbestand. Es kommt immer darauf an wofür es gebraucht wird.

laborix 13.12.2010 20:30

Danke euch beiden, das habe ich nicht gewusst.

Empfiehlt es sich allen internen Funktionen den gleichen Übergabe Parameter zu geben?

Praktikant 13.12.2010 22:15

Es empfiehlt sich logische Namen zu verwenden. Wie die heißen ist egal, ob es die selben meistens auch. Ich arbeite nicht gerne mit Klassenvariablen, die wollen so gerne initialisiert werden. Ich übergebe Parameter gerne in die Funktionen beim Aufruf. Wenn ich Objekte übergeben muss, dann kommen die in eine Klassenvariable. Aber sonst verwende ich die selten.

mantiz 14.12.2010 00:06

Zitat:

Zitat von Praktikant (Beitrag 482596)
Es empfiehlt sich logische Namen zu verwenden. Wie die heißen ist egal, ob es die selben meistens auch. Ich arbeite nicht gerne mit Klassenvariablen, die wollen so gerne initialisiert werden. Ich übergebe Parameter gerne in die Funktionen beim Aufruf. Wenn ich Objekte übergeben muss, dann kommen die in eine Klassenvariable. Aber sonst verwende ich die selten.

Heisst das, dass Du Klassen (Objekte) lediglich als Wrapper (Namespace) für Deine Funktionen nutzt?

Ich komme bei objektorientierter Programmierung nicht ohne Klassenvariablen bzw. Attributen aus, oder verstehe ich Dich hier falsch?

Praktikant 14.12.2010 01:16

Zitat:

Zitat von mantiz (Beitrag 482655)
Heisst das, dass Du Klassen (Objekte) lediglich als Wrapper (Namespace) für Deine Funktionen nutzt?

Ich komme bei objektorientierter Programmierung nicht ohne Klassenvariablen bzw. Attributen aus, oder verstehe ich Dich hier falsch?

Nein, das hast du richtig verstanden. So Sachen wir Benutzer ID oder sowas speicher ich auch in Klassenvariablen, aber das war es dann meistens schon. Ich versuche immer so viel möglich zu vererben, bis ich die Möglichkeiten des Vererbens sprenge. Das muss man dann zwar alles irgendwo aufschreiben, aber das ist ja machbar :mrgreen:

Allerdings ändert sich das in regelmäßigen Abständen. Mit kleinen Projekten probiere ich immer wieder andere Wege aus, den für mich Perfekten habe ich leider noch nicht gefunden.

mantiz 14.12.2010 10:27

OK, hatte mich nur mal interessiert.

Ich war selbst auch lange auf der Suche, dann mal viel Erfolg. ;)

Praktikant 14.12.2010 11:27

Wie machst du es denn? Wie gehst du mit Vererbung, Klassenvariablen und so weiter um?
Was überginst du eher an Klassenvariablen, was eher als Funktionsparameter?

Vielleicht kann ich bei dir ja was lernen :mrgreen:

mantiz 14.12.2010 11:56

Naja, ich habe da keine bestimmte Regel oder sowas.

Ich versuche sämtliche Variablen so lokal wie möglich zu halten und sämtliche Werte, welche Konfiguration oder Resourcen oder ähnliches sind im Objekt bzw. der Klasse zu speichern.

Als Beispiel hier mal die Attribute meines abstrakten Controllers:
PHP-Code:

protected $acl;
protected 
$auth;
protected 
$authAdapters = array();
protected 
$config;
protected 
$controllerKey;
protected 
$dbConnections = array();
protected 
$frontcontroller;
protected 
$messages = array();
protected 
$models = array();
protected 
$refClass;
protected 
$request;
protected 
$response;
protected 
$router;
protected 
$session;
protected 
$view

Hier die des Frontcontrollers welcher natürlich von AbstractController erbt:
PHP-Code:

protected $controllers = array();
protected 
$layoutEnabled true;
protected 
$preDispatchFilter;
protected 
$postDispatchFilter

Nun werden natürlich nicht sämtliche Attribute ständig verwendet, am Beispiel des Request-Objektes einmal verdeutlicht:

Das Request-Objekt, sowie sämtliche Controller, werden (standardmäßig) im Frontcontroller erstellt, dabei wird den Controllern die Instanz des Frontcontrollers übergeben.

Nun sieht die Methode getRequest() im AbstractController folgendermaßen aus (hier vereinfacht):
PHP-Code:

public function getRequest() {
    if (
$this->request !== null) {
        return 
$this->request;
    }
    
    if ((
$fc $this->getFrontcontroller()) !== null) {
        if (
$fc !== $this) { // avoid recursion
            
return $fc->getRequest();
        }
    }
    
    return 
null;


Auf die Art habe ich sämtliche Getter implementiert, so dass im Controller ein simples "$this->getRequest()" ausreicht, um an das richtige Objekt zu gelangen, ebenso wäre es aber möglich bestimmten Controllern ein anderes Request-Objekt zu geben.
Im Detail wäre es wohl zu viel alles zu erklären, hier nur mal als Idee.

Hier kommen imo nur Attribute in Frage, alles andere wäre unnötig kompliziert und redundant.

Ein anderes Beispiel wäre meine DbTable-Klasse, wo ich ein wenig von Zend abgeschaut habe, hier habe ich die Attribute:
PHP-Code:

protected $dbConnection;
protected 
$name;
protected 
$primary

In $dbConnection wird die aktuelle Datenbankverbindung gespeichert (inkl. Datenbank), $name enthält den Tabellennamen und $primary den Namen der Spalte, welche den Primärschlüssel angibt.
So kann man so schön kurze, sowie unabhängige Methoden wie z.B.:
PHP-Code:

public function find($primary) {
    return 
$this->fetch(array($this->primary => $primary));


schreiben, also z.B.
PHP-Code:

$commentModel = new DbTable($dbConnection'comments''id');
// ...
$comment $commentModel->find(1); 

anstelle von
PHP-Code:

$commentModel = new DbTable($dbConnection'comments''id');
// ...
$comment $commentModel->fetch(array('id' => 1)); 

Der Code wird imo generischer und besser wartbar.

Dazu sollte ich aber noch sagen, dass bei mir die Angaben zum Tabellennamen und Primärschlüssel ebensowenig im Code stehen (das habe ich hier nur kurz so gemacht), sondern per Config gesetzt werden.

So kann der Primärschlüssel z.B. von "id" nach "commentId" geändert werden, die Änderung wird in der Config-Datei vorgenommen und man ist fertig. ;)


Alle Zeitangaben in WEZ +2. Es ist jetzt 11:31 Uhr.

Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

© Dirk H. 2003 - 2023