[Erledigt] Getter & Setter in PHP - Seite 2

fab · 02.08.2011, 13:18

Wenn die Implementierung bzw. Nicht-Implementierung dabei aber so bleibt wie es aktuell aussieht, kann man sie auch in die Tonne kloppen:

http://schlueters.de/blog/archives/1...PHP-trunk.html

Codercrush · 02.08.2011, 13:21

Würde ja Null Sinn ergeben wenn es trotzdem ignoriert wird...

nikosch · 02.08.2011, 21:05

1/ __get und __set wirken nur auf nicht deklarierte Properties (bzw. private), was schon mal ein echter Nachteil ist, weil Eigenschaften nicht vorinitialisiert werden können.
2/ Die Bekanntmachung erfolgt im Konstruktor, was Vererbung erschwert oder zu Coderedundanz führt
3/ nutzende Klassen können nicht mehr von anderen abgeleitet werden

4/ Die setVar Methode ist uninspirierend allein in ihren Parametern
5/ $this->count stellt ja eben keinen Setter dar.
a) Im Ggs. zu einem Setter kannst Du hier keine Zusatzfunktionalität einbauen (z.B. Validierung)
b) Im Ggs. zu einem Setter kannst Du hier keine beschreibenden Namen verwenden, sondern bist immer an den Variablennamen gebunden
6/ Echte Getter/Setter kannst Du in einem Interface definieren und damit in anderen Kontexten auf diese Methoden aufbauen (auf die Existenz vertrauen). Deine Lösung ist implizit.

dsentker · 03.08.2011, 10:42

Hier noch was aus meiner Sinnlos-Kiste:

PHP-Code:

  
<?php

class AutoSetterGetter {


    public function __call($func, $params) {

        if(strpos($func, 'set') === 0) {
            // Setter
            $property = lcfirst(substr($func, 3));
            if(property_exists(get_class($this), $property) && isset($params[0])) {
                $this->{$property} = $params[0];
            }
        } elseif(strpos($func, 'get') === 0) {
            // Getter
            $property = lcfirst(substr($func, 3));
            if(property_exists(get_class($this), $property)) {
                return $this->{$property};
            }
        } else {
            trigger_error('Call to undefined method ' . __CLASS__ . '::' . $func, E_USER_ERROR);
        }
    }

}



class Test extends AutoSetterGetter {

    protected   $foo = 'bla';
    public      $bar = 'muh';

}


$a = new Test();
$a->setFoo('neuerWertFürFoo');
echo $a->getFoo();


?>

Die abstrakte Klasse macht es möglich, per __call automatisch setter und getter für protected und public properties zu setzen. Mit traits würde das ganze natürlich noch etwas schöner werden

xm22 · 03.08.2011, 11:07

Damit hast Du aber immer noch die meisten der von Nikosch angeführten Probleme..

dsentker · 03.08.2011, 13:28

Naja, das ist natürlich klar, bis auf

Zitat:

Im Ggs. zu einem Setter kannst Du hier keine beschreibenden Namen verwenden, sondern bist immer an den Variablennamen gebunden

Wie oft kommt es vor, dass sich der im Methodenname befindliche Variablenname von dem property unterscheidet?

Ansonsten: Mein Werk ist auch mehr Spielerei als wirklich nützlich. Moderne IDEs bieten bereits eine Automatisierung für getter/setter.

nikosch · 03.08.2011, 16:45

Das kommt auf den Stil an. Niemand schreibt vor, dass ich Klassenvaraiblen nicht spezifischer oder allgemeiner benenne. Manche benutzen für private Member führende Unterstriche, manchmal kommt es vor, dass bei der Ableitung von allgemeinen Funktionsklassen die Getter nicht sprechend genug sind.
Ein weiterer Punkt sind parameterisierte Getter. Z.B. benutze ich manchmal Getter, die ohne Parameter ein komplettes Array, mit Parameter nur den zum Schlüssel passenden Wert liefern. Selbstredend wäre ein solcher Parameter für Getter auf Skalarwerte Unsinn.

joshiausdemall · 03.08.2011, 17:15

Das klingt irgendwie fies. Wenn ich einen Parkplatz voller Autos habe, möchte ich mit getAutos() alle bekommen und mit getAuto($kennzeichen) gezielt eins suchen können.

nikosch · 03.08.2011, 18:15

Kannst Du für Dich auch gerne so machen. Ich wollte damit sagen, dass Getter/Setter mitnichten immer dem Schema [gs]et{PropertyName} folgen müssen. Gerade weil Objekte als Blackbox funktionieren, sollte man hier kein Konventionsnazi sein, sondern lieber mal nahe an der Domäne operieren. Denn ob ich intern ein Datum als Timestamp, Y/M/D Array oder sonstwie verwalte, kann dem Anwender egal sein und sollte nicht das Interface beeinflussen. Vielleicht treffe ich morgen eine Strukturentscheidung, das Innere der Klasse zu refaktorieren.

dsentker · 04.08.2011, 00:03

Du hast völlig Recht. Daher war meine Lösung auch eine reine Fingerübung und bringt wenig Mehrwert mit sich.

In einem Model z.B. finden sich in meinem Alltag häufig Methoden, die von [g|s]et{PropertyName} abweichen, etwa getEntryDateDe oder getFullName.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Implementierung vieler Getter bzw. Setter-Methoden	axelf	Software-Design	28	08.06.2011 17:10
Wiederkehrende Aufgaben (set, get, etc.)	elf	PHP Einsteiger	51	23.04.2011 21:04
Sinn und Zweck der Set und Get Methoden	Kevni	PHP Tipps 2010	10	09.09.2010 22:46
[Erledigt] Getter und statische Variable	stayInside	PHP Tipps 2009	0	27.01.2009 20:29

02.08.2011, 13:18
fab Erfahrener Benutzer Registriert seit: 28.07.2010 Beiträge: 2.308 PHP-Kenntnisse: Fortgeschritten	Wenn die Implementierung bzw. Nicht-Implementierung dabei aber so bleibt wie es aktuell aussieht, kann man sie auch in die Tonne kloppen: http://schlueters.de/blog/archives/1...PHP-trunk.html __________________ PHP Blog + Library CSS Effects + Tools


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

02.08.2011, 13:21
Codercrush Benutzer Registriert seit: 18.02.2010 Beiträge: 54 PHP-Kenntnisse: Fortgeschritten	Würde ja Null Sinn ergeben wenn es trotzdem ignoriert wird... __________________ Ich würde so gern die Welt verändern doch Gott gibt mir den Quellcode nicht. Compiler sind wie Franzosen.. schnauzen einen immer nur an, wenn man ihre Sprache nich perfekt spricht.

02.08.2011, 21:05
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	1/ __get und __set wirken nur auf nicht deklarierte Properties (bzw. private), was schon mal ein echter Nachteil ist, weil Eigenschaften nicht vorinitialisiert werden können. 2/ Die Bekanntmachung erfolgt im Konstruktor, was Vererbung erschwert oder zu Coderedundanz führt 3/ nutzende Klassen können nicht mehr von anderen abgeleitet werden 4/ Die setVar Methode ist uninspirierend allein in ihren Parametern 5/ $this->count stellt ja eben keinen Setter dar. a) Im Ggs. zu einem Setter kannst Du hier keine Zusatzfunktionalität einbauen (z.B. Validierung) b) Im Ggs. zu einem Setter kannst Du hier keine beschreibenden Namen verwenden, sondern bist immer an den Variablennamen gebunden 6/ Echte Getter/Setter kannst Du in einem Interface definieren und damit in anderen Kontexten auf diese Methoden aufbauen (auf die Existenz vertrauen). Deine Lösung ist implizit. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

03.08.2011, 10:42
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Hier noch was aus meiner Sinnlos-Kiste: PHP-Code: <?php class AutoSetterGetter { public function __call($func, $params) { if(strpos($func, 'set') === 0) { // Setter $property = lcfirst(substr($func, 3)); if(property_exists(get_class($this), $property) && isset($params[0])) { $this->{$property} = $params[0]; } } elseif(strpos($func, 'get') === 0) { // Getter $property = lcfirst(substr($func, 3)); if(property_exists(get_class($this), $property)) { return $this->{$property}; } } else { trigger_error('Call to undefined method ' . __CLASS__ . '::' . $func, E_USER_ERROR); } } } class Test extends AutoSetterGetter { protected $foo = 'bla'; public $bar = 'muh'; } $a = new Test(); $a->setFoo('neuerWertFürFoo'); echo $a->getFoo(); ?> Die abstrakte Klasse macht es möglich, per __call automatisch setter und getter für protected und public properties zu setzen. Mit traits würde das ganze natürlich noch etwas schöner werden __________________

03.08.2011, 11:07
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.169 PHP-Kenntnisse: Fortgeschritten	Damit hast Du aber immer noch die meisten der von Nikosch angeführten Probleme..

03.08.2011, 16:45
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Das kommt auf den Stil an. Niemand schreibt vor, dass ich Klassenvaraiblen nicht spezifischer oder allgemeiner benenne. Manche benutzen für private Member führende Unterstriche, manchmal kommt es vor, dass bei der Ableitung von allgemeinen Funktionsklassen die Getter nicht sprechend genug sind. Ein weiterer Punkt sind parameterisierte Getter. Z.B. benutze ich manchmal Getter, die ohne Parameter ein komplettes Array, mit Parameter nur den zum Schlüssel passenden Wert liefern. Selbstredend wäre ein solcher Parameter für Getter auf Skalarwerte Unsinn. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

03.08.2011, 17:15
joshiausdemall Neuer Benutzer Registriert seit: 15.06.2011 Beiträge: 14 PHP-Kenntnisse: Fortgeschritten	Das klingt irgendwie fies. Wenn ich einen Parkplatz voller Autos habe, möchte ich mit getAutos() alle bekommen und mit getAuto($kennzeichen) gezielt eins suchen können.

03.08.2011, 18:15
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Kannst Du für Dich auch gerne so machen. Ich wollte damit sagen, dass Getter/Setter mitnichten immer dem Schema [gs]et{PropertyName} folgen müssen. Gerade weil Objekte als Blackbox funktionieren, sollte man hier kein Konventionsnazi sein, sondern lieber mal nahe an der Domäne operieren. Denn ob ich intern ein Datum als Timestamp, Y/M/D Array oder sonstwie verwalte, kann dem Anwender egal sein und sollte nicht das Interface beeinflussen. Vielleicht treffe ich morgen eine Strukturentscheidung, das Innere der Klasse zu refaktorieren. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

04.08.2011, 00:03
dsentker Erfahrener Benutzer Registriert seit: 26.11.2008 Beiträge: 264	Du hast völlig Recht. Daher war meine Lösung auch eine reine Fingerübung und bringt wenig Mehrwert mit sich. In einem Model z.B. finden sich in meinem Alltag häufig Methoden, die von [g\|s]et{PropertyName} abweichen, etwa getEntryDateDe oder getFullName. __________________