Getter and Setter?

Nie jestem programistą PHP, więc zastanawiam się, czy w PHP bardziej popularne jest używanie jawnego gettera / settera, w czystym stylu OOP, z polami prywatnymi (tak jak lubię):

class MyClass {
    private $firstField;
    private $secondField;

    public function getFirstField() {
        return $this->firstField;
    }
    public function setFirstField($x) {
        $this->firstField = $x;
    }
    public function getSecondField() {
        return $this->secondField;
    }
    public function setSecondField($x) {
        $this->secondField = $x;
    }
}

lub po prostu pola publiczne:

class MyClass {
    public $firstField;
    public $secondField;
}

Dzięki

Możesz użyć magicznych metod php __get i __set.

<?php
class MyClass {
  private $firstField;
  private $secondField;

  public function __get($property) {
    if (property_exists($this, $property)) {
      return $this->$property;
    }
  }

  public function __set($property, $value) {
    if (property_exists($this, $property)) {
      $this->$property = $value;
    }

    return $this;
  }
}
?>

Dlaczego warto korzystać z getterów i seterów?

1. Skalowalność : łatwiej jest refaktorować getter niż przeszukiwać wszystkie przypisania var w kodzie projektu.
2. Debugowanie : Możesz ustawić punkty przerwania na ustawiających i pobierających.
3. Cleaner : Funkcje magiczne nie są dobrym rozwiązaniem do pisania mniej, twoje IDE nie sugeruje kodu. Lepiej używaj szablonów do szybkiego pisania.

Google opublikował już przewodnik na temat optymalizacji PHP, a wniosek był następujący:

Bez gettera i setera Optymalizacja PHP

I nie, nie wolno ci używać magicznych metod . Dla PHP metoda magiczna jest zła. Czemu?

1. Trudno je debugować.
2. Istnieje negatywny wpływ na wydajność.
3. Wymagają napisania więcej kodu.

PHP nie jest Java, C ++ ani C #. PHP jest inny i gra różnymi rolami.

Kapsułkowanie jest ważne w każdym języku OO, popularność nie ma z tym nic wspólnego. W dynamicznie wpisywanych językach, takich jak PHP, jest to szczególnie przydatne, ponieważ istnieje niewiele sposobów, aby upewnić się, że właściwość jest określonego typu bez użycia seterów.

W PHP działa to:

class Foo {
   public $bar; // should be an integer
}
$foo = new Foo;
$foo->bar = "string";

W Javie nie:

class Foo {
   public int bar;
}
Foo myFoo = new Foo();
myFoo.bar = "string"; // error

Korzystanie z magicznych metod ( __geti __set) również działa, ale tylko podczas uzyskiwania dostępu do właściwości, która ma mniejszą widoczność niż obecny zakres może uzyskać. Może z łatwością wywoływać bóle głowy podczas próby debugowania, jeśli nie jest właściwie używany.

Jeśli wolisz korzystać z funkcji __call, możesz użyć tej metody. Działa z

• GET => $this->property()
• SET => $this->property($value)
• GET => $this->getProperty()
• SET => $this->setProperty($value)

kalsdas

public function __call($name, $arguments) {

    //Getting and setting with $this->property($optional);

    if (property_exists(get_class($this), $name)) {


        //Always set the value if a parameter is passed
        if (count($arguments) == 1) {
            /* set */
            $this->$name = $arguments[0];
        } else if (count($arguments) > 1) {
            throw new \Exception("Setter for $name only accepts one parameter.");
        }

        //Always return the value (Even on the set)
        return $this->$name;
    }

    //If it doesn't chech if its a normal old type setter ot getter
    //Getting and setting with $this->getProperty($optional);
    //Getting and setting with $this->setProperty($optional);
    $prefix = substr($name, 0, 3);
    $property = strtolower($name[3]) . substr($name, 4);
    switch ($prefix) {
        case 'get':
            return $this->$property;
            break;
        case 'set':
            //Always set the value if a parameter is passed
            if (count($arguments) != 1) {
                throw new \Exception("Setter for $name requires exactly one parameter.");
            }
            $this->$property = $arguments[0];
            //Always return the value (Even on the set)
            return $this->$name;
        default:
            throw new \Exception("Property $name doesn't exist.");
            break;
    }
}

Oprócz świetnych i szanowanych odpowiedzi tutaj chciałbym rozwinąć PHP bez żadnych setterów / getterów.

PHP nie ma składni gettera i settera . Zapewnia podklasowe lub magiczne metody umożliwiające „zaczepienie” i przesłonięcie procesu wyszukiwania właściwości, jak zauważył Dave .

Magic pozwala nam leniwym programistom robić więcej przy mniejszym kodzie w czasie, gdy jesteśmy aktywnie zaangażowani w projekt i znamy go dokładnie, ale zwykle kosztem czytelności.

Wydajność Każda niepotrzebna funkcja, która wynika z wymuszenia architektury kodu przypominającej getter / setter w PHP, obejmuje własną ramkę stosu pamięci podczas wywoływania i marnuje cykle procesora.

Czytelność: podstawa kodu powoduje wzdęcie linii kodu, co wpływa na nawigację po kodzie, ponieważ więcej LOC oznacza więcej przewijania.

Preferencje: Osobiście, zgodnie z moją ogólną zasadą, traktuję niepowodzenie analizy kodu statycznego jako znak, aby uniknąć pójścia magiczną drogą, o ile w tym czasie wymykają mi się oczywiste długoterminowe korzyści.

Błędy:

Częstym argumentem jest czytelność. Na przykład $someobject->widthjest to łatwiejsze do odczytania niż $someobject->width(). Jednak w odróżnieniu od planety circumferencelub width, jak można to założyć static, instancji obiektu, takiej jak $someobject, która wymaga funkcji szerokości, prawdopodobnie mierzy szerokość instancji obiektu.
Dlatego czytelność zwiększa się głównie z powodu asertywnych schematów nazewnictwa, a nie przez ukrycie funkcji, która generuje daną wartość właściwości.

__get / __set używa:

• wstępna walidacja i wstępna dezynfekcja wartości nieruchomości

• struny np

  "
  some {mathsobj1->generatelatex} multi
  line text {mathsobj1->latexoutput}
  with lots of variables for {mathsobj1->generatelatex}
   some reason
  "

  W takim przypadku generatelatexzastosowałby się schemat nazewnictwa akcji nazwa + nazwa metody

• specjalne, oczywiste przypadki

  $dnastringobj->homeobox($one_rememberable_parameter)->gattaca->findrelated()
  $dnastringobj->homeobox($one_rememberable_parameter)->gttccaatttga->findrelated()

Uwaga: PHP zdecydowało się nie implementować składni getter / setter. Nie twierdzę, że osoby pobierające / ustawiające są ogólnie złe.

class MyClass {
    private $firstField;
    private $secondField;
    private $thirdField;

    public function __get( $name ) {
        if( method_exists( $this , $method = ( 'get' . ucfirst( $name  ) ) ) )
            return $this->$method();
        else
            throw new Exception( 'Can\'t get property ' . $name );
    }

    public function __set( $name , $value ) {
        if( method_exists( $this , $method = ( 'set' . ucfirst( $name  ) ) ) )
            return $this->$method( $value );
        else
            throw new Exception( 'Can\'t set property ' . $name );
    }

    public function __isset( $name )
    {
        return method_exists( $this , 'get' . ucfirst( $name  ) ) 
            || method_exists( $this , 'set' . ucfirst( $name  ) );
    }

    public function getFirstField() {
        return $this->firstField;
    }

    protected function setFirstField($x) {
        $this->firstField = $x;
    }

    private function getSecondField() {
        return $this->secondField;
    }
}

$obj = new MyClass();

echo $obj->firstField; // works
$obj->firstField = 'value'; // works

echo $obj->getFirstField(); // works
$obj->setFirstField( 'value' ); // not works, method is protected

echo $obj->secondField; // works
echo $obj->getSecondField(); // not works, method is private

$obj->secondField = 'value'; // not works, setter not exists

echo $obj->thirdField; // not works, property not exists

isset( $obj->firstField ); // returns true
isset( $obj->secondField ); // returns true
isset( $obj->thirdField ); // returns false

Gotowy!

Cóż, PHP ma magicznych sposobów __get, __set, __isseti __unset, co jest zawsze początek. Niestety właściwe (rozumiesz?) Właściwości OO to coś więcej niż metody magiczne. Główny problem z implementacją PHP polega na tym, że wywoływane są magiczne metody dla wszystkich niedostępnych właściwości. Co oznacza, że ​​musisz powtórzyć się (np. Wywołując property_exists ()) w magicznych metodach podczas określania, czy imię jest faktycznie własnością twojego obiektu. I tak naprawdę nie możesz rozwiązać tego ogólnego problemu z klasą podstawową, chyba że wszystkie twoje klasy dziedziczą np. ClassWithProperties, ponieważ PHP nie ma wielokrotnego dziedziczenia.

W przeciwieństwie do tego, nowe klasy stylu Pythona dają ci property()możliwość jawnego zdefiniowania wszystkich swoich właściwości. C # ma specjalną składnię.

http://en.wikipedia.org/wiki/Property_(programming)

Zrobiłem eksperyment przy użyciu magicznej metody __call. Nie jestem pewien, czy powinienem to opublikować (z powodu wszystkich ostrzeżeń „NIE UŻYWAJ METOD MAGICZNYCH” w innych odpowiedziach i komentarzach), ale zostawię to tutaj… na wypadek, gdyby ktoś uznał to za przydatne.

public function __call($_name, $_arguments){
    $action  = substr($_name, 0, 4);
    $varName = substr($_name, 4);

    if (isset($this->{$varName})){
        if ($action === "get_") return $this->{$varName};
        if ($action === "set_") $this->{$varName} = $_arguments[0];
    }
}

Po prostu dodaj tę metodę powyżej w swojej klasie, teraz możesz wpisać:

class MyClass{
    private foo = "bar";
    private bom = "bim";
    // ...
    // public function __call(){ ... }
    // ...
}
$C = new MyClass();

// as getter
$C->get_foo(); // return "bar"
$C->get_bom(); // return "bim"

// as setter
$C->set_foo("abc"); // set "abc" as new value of foo
$C->set_bom("zam"); // set "zam" as new value of bom

W ten sposób możesz pobrać / ustawić wszystko w swojej klasie, jeśli istnieje, więc jeśli potrzebujesz go tylko dla kilku konkretnych elementów, możesz użyć „białej listy” jako filtra.

Przykład:

private $callWhiteList = array(
    "foo" => "foo",
    "fee" => "fee",
    // ...
);

public function __call($_name, $_arguments){
    $action  = substr($_name, 0, 4);
    $varName = $this->callWhiteList[substr($_name, 4)];

    if (!is_null($varName) && isset($this->{$varName})){
        if ($action === "get_") return $this->{$varName};
        if ($action === "set_") $this->{$varName} = $_arguments[0];
    }
}

Teraz możesz tylko ustawić / ustawić „foo” i „opłata”.
Możesz także użyć tej „białej listy”, aby przypisać niestandardowe nazwy dostępu do swoich zmiennych.
Na przykład,

private $callWhiteList = array(
    "myfoo" => "foo",
    "zim" => "bom",
    // ...
);

Na tej liście możesz teraz wpisać:

class MyClass{
    private foo = "bar";
    private bom = "bim";
    // ...
    // private $callWhiteList = array( ... )
    // public function __call(){ ... }
    // ...
}
$C = new MyClass();

// as getter
$C->get_myfoo(); // return "bar"
$C->get_zim(); // return "bim"

// as setter
$C->set_myfoo("abc"); // set "abc" as new value of foo
$C->set_zim("zam"); // set "zam" as new value of bom

.
.
.
To wszystko.

Doc: __call () jest wyzwalany podczas wywoływania niedostępnych metod w kontekście obiektowym.

Po przeczytaniu innych rad mam skłonność powiedzieć, że:

Jako GENERIC reguły nie zawsze określają ustawiające dla WSZYSTKICH właściwości, szczególnie te „wewnętrzne” (semafory, wewnętrzne flagi ...). Oczywiście właściwości tylko do odczytu nie będą miały ustawiających, więc niektóre właściwości będą miały tylko ustawiające; tam właśnie przychodzi __get (), aby zmniejszyć kod:

• zdefiniuj __get () (magiczne globalne gettery) dla wszystkich podobnych właściwości,
• zgrupuj je w tablice, aby:
  • będą miały wspólne cechy: wartości pieniężne będą / mogą pojawiać się odpowiednio sformatowane, daty w określonym układzie (ISO, USA, międzynarodowe) itp.
  • sam kod może zweryfikować, że tylko istniejące i dozwolone właściwości są odczytywane przy użyciu tej magicznej metody.
  • ilekroć potrzebujesz utworzyć nową podobną właściwość, po prostu ją zadeklaruj i dodaj jej nazwę do odpowiedniej tablicy i gotowe. Jest to o wiele SZYBCIEJ niż definiowanie nowego programu pobierającego, być może z kilkoma wierszami kodu powtarzanymi wielokrotnie w całym kodzie klasy.

Tak! moglibyśmy napisać prywatną metodę, aby to zrobić, ale wtedy znowu będziemy WIELU metod zadeklarowanych (pamięć ++), które w końcu wywołują inną, zawsze tę samą, metodę. Dlaczego nie napisać POJEDYNCZEJ metody, by rządzić nimi wszystkimi ...? [tak! kalambur absolutnie przeznaczony! :)]

Ustawiacze magii mogą również reagować TYLKO na określone właściwości, więc wszystkie właściwości typu daty mogą być sprawdzane pod kątem nieprawidłowych wartości tylko w jednej metodzie. Jeśli właściwości typu daty były wymienione w tablicy, ich ustawiacze można łatwo zdefiniować. Oczywiście tylko przykład. jest zbyt wiele sytuacji.

O czytelności ... Cóż ... To kolejna debata: Nie lubię być związana z użyciem IDE (w rzeczywistości nie używam ich, zwykle mówią mi (i zmuszają ) jak pisz ... a ja lubię kodować „piękno”). Zwykle jestem konsekwentny w nazywaniu, więc używanie tagów i kilku innych pomocy jest dla mnie wystarczające ... W każdym razie: kiedy wszystkie te magiczne setery i gettery są skończone, piszę inne sety, które są zbyt specyficzne lub „specjalne”, aby być uogólnione w metodzie __set (). I to wszystko, czego potrzebuję, aby uzyskać i ustawić właściwości. Oczywiście: nie zawsze istnieje wspólna płaszczyzna lub istnieje kilka takich właściwości, które nie są warte kłopotu z kodowaniem magicznej metody, a ponadto istnieje stara, dobra, tradycyjna para setter / getter.

Języki programowania są po prostu: sztuczne języki ludzkie. Każdy z nich ma swoją intonację lub akcent, składnię i smak, więc nie będę udawał, że piszę kod Ruby lub Python przy użyciu tego samego „akcentu” niż Java lub C #, ani nie napisałbym JavaScript ani PHP, aby przypominać Perl lub SQL ... Używaj ich tak, jak powinny.

Ogólnie rzecz biorąc, pierwszy sposób jest ogólnie bardziej popularny, ponieważ osoby posiadające wcześniejszą wiedzę programistyczną mogą łatwo przejść na PHP i wykonywać pracę w sposób obiektowy. Pierwszy sposób jest bardziej uniwersalny. Radzę trzymać się tego, co sprawdzone i sprawdzone w wielu językach. Następnie, gdy używasz innego języka, będziesz gotowy, aby coś osiągnąć ( zamiast spędzać czas na nowo wymyślając koło ).

Istnieje wiele sposobów tworzenia kodu źródłowego w konwencji netbeans. To jest miłe. Ułatwia to myślenie === FAŁSZ. Po prostu skorzystaj z tradycji, zwłaszcza jeśli nie masz pewności, która z właściwości powinna zostać zamknięta, a która nie. Wiem, to jest kod boi .... pla ..., ale do debugowania działa i wiele innych uważa, że ​​jest to lepszy, wyraźniejszy sposób. Nie spędzaj zbyt wiele czasu z tysiącami sztuk, jak robić proste gettery i setery. Nie możesz zaimplementować niektórych wzorców projektowych, takich jak zasada demeter i tak dalej, jeśli używasz magii. W konkretnej sytuacji możesz użyć magic_calls lub małych, szybkich i przejrzystych rozwiązań. Na pewno możesz w ten sposób tworzyć rozwiązania dla wzorników projektowych, ale po co utrudniać ci życie.

Sprawdzanie poprawności + formatowanie / wyprowadzanie wartości

Settery umożliwiają sprawdzanie poprawności danych, a gettery umożliwiają formatowanie lub uzyskiwanie danych. Obiekty umożliwiają enkapsulację danych oraz ich walidację i formatowanie kodu w zgrabny pakiet, który zachęca do OSUSZANIA.

Rozważmy na przykład następującą prostą klasę, która zawiera datę urodzenia.

class BirthDate {

    private $birth_date;

    public function getBirthDate($format='Y-m-d') {
        //format $birth_date ...
        //$birth_date = ...
        return $birth_date;
    }

    public function setBirthDate($birth_date) {                   
        //if($birth_date is not valid) throw an exception ...          
        $this->birth_date = $birth_date;
    }

    public function getAge() {
        //calculate age ...
        return $age;
    }

    public function getDaysUntilBirthday() {
        //calculate days until birth days
        return $days;
    }
}

Będziesz chciał sprawdzić, czy ustawiana jest wartość

• Prawidłowa data
• Nie w przyszłości

I nie chcesz przeprowadzać tej weryfikacji w całej aplikacji (lub w wielu aplikacjach). Zamiast tego łatwiej jest ustawić zmienną członkowską jako chronioną lub prywatną (aby setter był jedynym punktem dostępu) i sprawdzić poprawność w seterze, ponieważ wtedy będziesz wiedział, że obiekt zawiera prawidłową datę urodzenia bez względu na to, która część aplikacja, z której pochodzi obiekt, a jeśli chcesz dodać więcej walidacji, możesz dodać ją w jednym miejscu.

Może chcesz dodać wiele formatek, które działają na tej samej zmiennej, tj członek getAge()i getDaysUntilBirthday(), a może chcesz wymusić konfigurowalny format, w getBirthDate()zależności od kraju. Dlatego wolę konsekwentnie uzyskiwać dostęp do wartości za pośrednictwem metod pobierających zamiast mieszać się $date->getAge()z $date->birth_date.

metody pobierające i ustawiające są również przydatne podczas rozszerzania obiektów. Załóżmy na przykład, że Twoja aplikacja musiała pozwalać na ponad 150-letnie daty urodzenia w niektórych miejscach, ale w innych nie. Jednym ze sposobów rozwiązania problemu bez powtarzania jakiegokolwiek kodu byłoby rozszerzenie BirthDateobiektu i umieszczenie dodatkowej weryfikacji w seterze.

class LivingBirthDate extends BirthDate {

    public function setBirthDate($birth_date) {
        //if $birth_date is greater than 150 years throw an exception
        //else pass to parent's setter
        return parent::setBirthDate($birth_date);
    }
}

Ten post nie jest konkretnie o __geta __setraczej __callktóry jest taki sam pomysł z wyjątkiem metody powołania. Z reguły trzymam się z daleka od wszelkiego rodzaju magicznych metod, które pozwalają na przeładowanie z powodów opisanych w komentarzach i postach, JEDNAK ostatnio natknąłem się na interfejs API innej firmy, którego używam, który korzysta z usługi SERVICE i SUB-SERVICE, na przykład :

http://3rdparty.api.com?service=APIService.doActionOne&apikey=12341234

Ważną częścią tego jest to, że ten interfejs API ma w tym przypadku wszystko to samo oprócz poddziałania doActionOne. Chodzi o to, że programista (ja i ​​inni korzystający z tej klasy) może wywołać pod-usługę z nazwy, w przeciwieństwie do czegoś takiego:

$myClass->doAction(array('service'=>'doActionOne','args'=>$args));

Mógłbym zamiast tego:

 $myClass->doActionOne($args);

W przypadku kodu twardego byłoby to po prostu dużo powielania (ten przykład bardzo luźno przypomina kod):

public function doActionOne($array)
    {
        $this->args     =   $array;
        $name           =   __FUNCTION__;
        $this->response =   $this->executeCoreCall("APIService.{$name}");
    }

public function doActionTwo($array)
    {
        $this->args     =   $array;
        $name           =   __FUNCTION__;
        $this->response =   $this->executeCoreCall("APIService.{$name}");
    }

public function doActionThree($array)
    {
        $this->args     =   $array;
        $name           =   __FUNCTION__;
        $this->response =   $this->executeCoreCall("APIService.{$name}");
    }

protected function executeCoreCall($service)
    {
        $cURL = new \cURL();
        return $cURL->('http://3rdparty.api.com?service='.$service.'&apikey='.$this->api.'&'.http_build_query($this->args))
                    ->getResponse();
    }

Ale dzięki magicznej metodzie __call()jestem w stanie uzyskać dostęp do wszystkich usług za pomocą metod dynamicznych:

public function __call($name, $arguments)
    {
        $this->args     =   $arguments;
        $this->response =   $this->executeCoreCall("APIService.{$name}");   
        return $this;
    }

Zaletą tego dynamicznego wezwania do zwrotu danych jest to, że jeśli dostawca doda inną pod-usługę, nie muszę dodawać innej metody do klasy ani tworzyć rozszerzonej klasy itp. Nie jestem pewien, czy jest to przydatne ktoś, ale pomyślałem, że pokażę przykład, w którym __set, __get, __call, itd. może być opcja do rozważenia, ponieważ podstawową funkcją jest powrót danych.

EDYTOWAĆ:

Przypadkowo zobaczyłem to kilka dni po opublikowaniu, które dokładnie opisuje mój scenariusz. Nie chodzi o API, o którym mówiłem, ale zastosowanie metod jest identyczne:

Czy używam poprawnie interfejsu API?

Aktualizacja: nie używaj tej odpowiedzi, ponieważ jest to bardzo głupi kod, który znalazłem podczas nauki. Wystarczy użyć zwykłego gettera i setera, jest o wiele lepszy.

Zwykle używam tej nazwy zmiennej jako nazwy funkcji i dodam opcjonalny parametr do tej funkcji, więc gdy ten opcjonalny parametr zostanie wypełniony przez obiekt wywołujący, następnie ustaw go na właściwość i zwróć $ ten obiekt (łańcuch), a następnie, gdy ten opcjonalny parametr nie zostanie określony przez dzwoniącym, właśnie zwracam właściwość dzwoniącemu.

Mój przykład:

class Model
{
     private $propOne;
     private $propTwo;

     public function propOne($propVal = '')
     {
          if ($propVal === '') {
              return $this->propOne;
          } else {
              $this->propOne = $propVal;
              return $this;
          }
     }

     public function propTwo($propVal = '')
     {
          if ($propVal === '') {
              return $this->propTwo;
          } else {
              $this->propTwo = $propVal;
              return $this;
          }
     }
}