private oder public

[ricola]

Hallo,

mir ist aufgefallen, das in vielen bestehenden Extensions oder bei neuen, duch den Extensioncreator angelegten Modulen, alle Klassen und Methoden mit public definiert sind. Das ist ja soweit auch ok so, falls andere diese Methoden mal nutzen wollen. Jedoch bin ich mir nicht sicher, ob das immer so gut oder gewollt ist.

Was spricht dagegen, die Methoden folgendermaßen zu gestalten:

class meineklasse {

    private function machedies ($variable) {
        .....
        return $machewas;
    }

    public function machedas ($variable) {

    return self::machedies($variable);
   }
} 

Durch die Kapselung gibt es doch im Endeffekt für das ganze System auch mehr Sicherheit. Oder was meint Ihr?

LG. Rico

[hschottm]

Hallo Rico,

klar ist das in Ordnung, wenn du nicht nur public Methoden verwendest. Ich würde dir allerdings empfehlen, Methoden, von denen du denkst, dass sie von Erweiterungen wiederverwendet werden könnten, protected statt private zu deklarieren. Damit sind diese Methoden wenigstens für Nachfahren deiner Klassen zugreifbar. Gerade wenn man mit einer Erweiterung eine bestehende Klasse "verfeinern" will, ist es immer sehr hilfreich, wenn die geschützen Methoden protected deklariert sind, weil es einem dann oft erspart bleibt, bestimmte Methoden einfach durch Kopieren zu übernehmen, weil man durch die private-Deklaration nicht rankommt.

Leo hat einen Großteil der Core-Klassen mittlerweile konsequent auf protected umgestellt, was uns Erweiterungsentwicklern die Arbeit ungemein erleichtert.

Public würde ich aber auch nur dann verwenden, wenn die Methoden nachweisbar von anderen Klassen genutzt werden sollen.

Gruß,
Helmut

[ricola]

Gerade wenn man mit einer Erweiterung eine bestehende Klasse "verfeinern" will, ist es immer sehr hilfreich, wenn die geschützen Methoden protected deklariert sind, weil es einem dann oft erspart bleibt, bestimmte Methoden einfach durch Kopieren zu übernehmen, weil man durch die private-Deklaration nicht rankommt.

Ja, das stimmt, und die absolute Restriktion wäre für die Klasse ja noch die clone() {}.
Ich fragte mich nur, warum ich für eine wahrscheinlich sowieso nicht erweiterbare Minianwendung public verwenden sollte. Generell hast Du natürlich recht, durch protected Methoden kann man wenigstens über die Klasse noch auf die Methode zugreifen und sie so ggf. erweitern. Hm, naja, wie schon so häufig ist hier wohl der Mittelweg der Königsweg.

Ich wollte ja nur versuchen, es von Anfang an so richtig wie möglich zu machen

LG. Rico

[andreas.schempp]

Public wird überall benötigt, wo etwas als Hook aufgerufen wird. Das ist in TYPOlight doch recht oft der Fall...

Ein gutes Beispiel findest du beim Modul

public function generate() { } 

protected function compile() { } 

Das ist in TYPOlight schon durchdacht. generate() wird vom Controller aufgerufen, wenn das Modul generiert wird, weshalb es public sein muss. compile() wird von generate() in der Modul-Klasse aufgerufen, weshalb es protected ist.

[ricola]

Public wird überall benötigt, wo etwas als Hook aufgerufen wird.

Ja, genau dort ist es mir ja auch aufgefallen. Ich habe s jetzt so gelöst:

$GLOBALS['TL_HOOKS']['outputFrontendTemplate'][] = array('GlossaryFP', 'StrOutput'); 

und die Klasse bzw. die Methoden:

class GlossaryFP extends Frontend {
    private function GlossaryItems($strContent) {
          ...
          return $strContent;
        }

       public function StrOutput($strContent) {
         return self::GlossaryItems($strContent);
       }
} 

Da ich für den Hoo jetzt auch noch ein Frontend/Backend Modul schreiben möchte, werde ich dann siehe Deinem Posting mit protected arbeiten.

Danke.
Rico

[FloB]

Warum rufst du die Methode als static auf? Ein Objekt der Klasse wird eh erzeugt, somit ist es doch eher sinnlos nochmal einen Umweg über eine statische Methode zu machen und nicht so:

return $this->GlossaryItems() 

[ricola]

Warum rufst du die Methode als static auf? Ein Objekt der Klasse wird eh erzeugt, somit ist es doch eher sinnlos nochmal einen Umweg über eine statische Methode zu machen und nicht so:

return $this->GlossaryItems() 

Das hat genau drei Gründe

• Zend gibt mir das komfortablerweise schon in einem Kontextmenü vor
• Ich habe das so gelent, dass innerhalb der Klasse mit self und abgeleitet mit parent gearbeitet wird
• Ich das bis jetzt noch nicht so kannte und auch nicht sicher gewesen wäre, ob das dann mit private kollidiert.

Naja, wieder was dazugelernt

Danke. Rico

[FloB]

Siehe http://de2.php.net/manual/de/language.oop5.static.php, http://de2.php.net/manual/de/languag...ekudotayim.php und sowieso immer http://www.professionelle-softwareen...g-mit-php5.de/.

Unstatische Methoden statisch aufzurufen ruft eine Warnung der Stufe E_STRICT hervor.

[ricola]

Siehe ....

Ja, das ist richtig so. Aber, siehe hier,

ist ein Kürzel, das Zugriff auf statische, konstante und überschriebene Member oder Methoden einer Klasse erlaubt

. Siehe Beispiel #3 Eine Vatermethode aufrufen, da dort per parent:: natürlich so die Elternmethode aufgerufen wird - warum dann nicht so in der eigenen Klasse...

Ok, wie dem auch sein - Du hast sicher recht - ich kenne mich in OOP nicht genügend aus, um das wirklich adäquat beurteilen zu können (auch wenn Zweifel bleiben - verschiedene Autoren, verschiedene Meinungen) - zukünftig arbeite ich dann mit $this.

LG. Rico

[FloB]

ist ein Kürzel, das Zugriff auf statische, konstante und überschriebene Member oder Methoden einer Klasse erlaubt

So einfach ist das nicht. Wenn du die Methode überschreibst, wird nicht automatisch mit dem Aufruf der Elternmethode die Kindmethode benutzt. Dafür musst du die Kindklasse komplett aufrufen. Somit fällt der von dir gewünschte Effekt (so, wie ich das verstanden habe) weg.