Getter y Setter?

No soy un desarrollador de PHP, por lo que me pregunto si en PHP es más popular usar getter / setters explícitos, en un estilo OOP puro, con campos privados (como a mí me gusta):

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;
    }
}

o solo campos públicos:

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

Gracias

Puedes usar métodos mágicos __get y php__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;
  }
}
?>

¿Por qué usar getters y setters?

1. Escalabilidad : es más fácil refactorizar un getter que buscar todas las asignaciones var en un código de proyecto.
2. Depuración : puede poner puntos de interrupción en setters y getters.
3. Más limpio : las funciones mágicas no son una buena solución para escribir menos, su IDE no le sugerirá el código. Mejor uso de plantillas para captadores de escritura rápida.

Google ya publicó una guía sobre la optimización de PHP y la conclusión fue:

Sin getter y setter Optimizando PHP

Y no, no debes usar métodos mágicos . Para PHP, los métodos mágicos son malos. ¿Por qué?

1. Son difíciles de depurar.
2. Hay un impacto negativo en el rendimiento.
3. Requieren escribir más código.

PHP no es Java, C ++ o C #. PHP es diferente y juega con diferentes roles.

La encapsulación es importante en cualquier lenguaje OO, la popularidad no tiene nada que ver con eso. En lenguajes de tipo dinámico, como PHP, es especialmente útil porque hay pocas formas de garantizar que una propiedad sea de un tipo específico sin usar setters.

En PHP, esto funciona:

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

En Java, no:

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

El uso de métodos mágicos ( __gety __set) también funciona, pero solo cuando se accede a una propiedad que tiene una visibilidad inferior a la que puede acceder el alcance actual. Puede causarle dolores de cabeza fácilmente cuando intenta depurar, si no se usa correctamente.

Si prefiere usar la función __call, puede usar este método. Funciona con

• OBTENER => $this->property()
• SET => $this->property($value)
• OBTENER => $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;
    }
}

Además de las respuestas ya excelentes y respetadas aquí, me gustaría expandirme en PHP que no tiene setters / getters.

PHP no tiene sintaxis getter y setter . Proporcionamétodossubclases o mágicos para permitir "enganchar" y anular el proceso de búsqueda de propiedades, como señaló Dave .

Magic nos permite a los programadores perezosos hacer más con menos código en un momento en el que participamos activamente en un proyecto y lo conocemos íntimamente, pero generalmente a expensas de la legibilidad.

Rendimiento Cada función innecesaria, que resulta de forzar una arquitectura de código tipo getter / setter en PHP, involucra su propio marco de pila de memoria al invocarlo y está desperdiciando ciclos de CPU.

Legibilidad: la base de código incurre en líneas de código hinchadas, lo que afecta la navegación de código, ya que más LOC significa más desplazamiento.

Preferencia: Personalmente, como regla general, tomo la falla del análisis de código estático como una señal para evitar seguir el camino mágico siempre que los obvios beneficios a largo plazo se me escapen en ese momento.

Falacias:

Un argumento común es la legibilidad. Por ejemplo, eso $someobject->widthes más fácil de leer que $someobject->width(). Sin embargo, a diferencia de un planeta circumferenceo width, que se puede suponer que es static, la instancia de un objeto como $someobject, que requiere una función de ancho, probablemente tome una medida del ancho de la instancia del objeto.
Por lo tanto, la legibilidad aumenta principalmente debido a esquemas de nombres asertivos y no al ocultar la función que genera un valor de propiedad dado.

__get / __set utiliza:

• prevalidación y pre-saneamiento de valores de propiedad

• cadenas por ejemplo

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

  En este caso generatelatexse adheriría a un esquema de nombres de actionname + methodname

• casos especiales y obvios

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

Nota: PHP eligió no implementar la sintaxis getter / setter. No estoy afirmando que getters / setter sean generalmente malos.

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

¡Listo!

Bueno, PHP tiene métodos mágicos __get, __set, __issety __unset, lo que es siempre un comienzo. Por desgracia, las propiedades de OO (¿entiendes?) Son más que métodos mágicos. El principal problema con la implementación de PHP es que se requieren métodos mágicos para todas las propiedades inaccesibles. Lo que significa que debe repetirse (por ejemplo, llamando a property_exists ()) en los métodos mágicos al determinar si el nombre es realmente una propiedad de su objeto. Y realmente no puede resolver este problema general con una clase base a menos que todas sus clases hereden de ie. ClassWithProperties, ya que PHP carece de herencia múltiple.

Por el contrario, Python le ofrece nuevas clases de estilo property(), que le permiten definir explícitamente todas sus propiedades. C # tiene una sintaxis especial.

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

Hice un experimento usando el método mágico __call. No estoy seguro de si debería publicarlo (debido a todas las advertencias de "NO UTILIZAR MÉTODOS MÁGICOS" en las otras respuestas y comentarios) pero lo dejaré aquí ... en caso de que alguien lo encuentre útil.

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];
    }
}

Simplemente agregue ese método arriba en su clase, ahora puede escribir:

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

De esta manera, puede obtener / configurar todo en su clase si existe, si lo necesita solo para unos pocos elementos específicos, puede usar una "lista blanca" como filtro.

Ejemplo:

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];
    }
}

Ahora solo puede obtener / configurar "foo" y "fee".
También puede usar esa "lista blanca" para asignar nombres personalizados para acceder a sus variables.
Por ejemplo,

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

Con esa lista ahora puede escribir:

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

.
.
.
Eso es todo.

Doc: __call () se activa al invocar métodos inaccesibles en un contexto de objeto.

Después de leer los otros consejos, me inclino a decir que:

Como regla GENÉRICA , no siempre definirá definidores para TODAS las propiedades, especialmente las "internas" (semáforos, marcas internas ...). Las propiedades de solo lectura no tendrán setters, obviamente, por lo que algunas propiedades solo tendrán getters; ahí es donde __get () llega a reducir el código:

• defina un __get () (captadores globales mágicos) para todas esas propiedades que son similares,
• agrúpelos en matrices para que:
  • compartirán características comunes: los valores monetarios aparecerán / pueden formatearse correctamente, las fechas en un diseño específico (ISO, EE. UU., Intl.), etc.
  • el código en sí mismo puede verificar que solo las propiedades existentes y permitidas se lean utilizando este método mágico.
  • cada vez que necesite crear una nueva propiedad similar, simplemente declare y agregue su nombre a la matriz adecuada y listo. Eso es MÁS RÁPIDO que definir un nuevo captador, tal vez con algunas líneas de código REPETIDAS una y otra vez en todo el código de la clase.

¡Si! podríamos escribir un método privado para hacer eso, también, pero de nuevo, tendremos MUCHOS métodos declarados (memoria ++) que terminan llamando a otro método, siempre el mismo. ¿Por qué no escribir una SOLA método para gobernarlos a todos ...? [¡Sí! juego de palabras absolutamente previsto! :)]

Los establecedores de magia también pueden responder SOLAMENTE a propiedades específicas, por lo que todas las propiedades de tipo de fecha se pueden seleccionar contra valores no válidos en un solo método. Si las propiedades de tipo de fecha se enumeran en una matriz, sus definidores se pueden definir fácilmente. Solo un ejemplo, por supuesto. Hay demasiadas situaciones.

Sobre la legibilidad ... Bueno ... Eso es otro debate: no me gusta estar vinculado a los usos de un IDE (de hecho, yo no uso de ellos, tienden a decirme (y obligar a mí) cómo escribir ... y tengo mis gustos sobre la codificación de "belleza"). Tiendo a ser coherente con los nombres, por lo que usar ctags y un par de otras ayudas es suficiente para mí ... De todos modos: una vez que todos estos setters y getters mágicos están listos, escribo los otros setters que son demasiado específicos o "especiales" para se generalizará en un método __set (). Y eso cubre todo lo que necesito para obtener y configurar propiedades. Por supuesto: no siempre hay un terreno en común, o hay unas pocas propiedades que no merecen la molestia de codificar un método mágico, y luego sigue existiendo el viejo buen setter / getter tradicional.

Los lenguajes de programación son solo eso: lenguajes artificiales humanos. Entonces, cada uno de ellos tiene su propia entonación o acento, sintaxis y sabor, por lo que no pretendo escribir un código Ruby o Python usando el mismo "acento" que Java o C #, ni escribiría un JavaScript o PHP para parecerse Perl o SQL ... Úselos de la forma en que están destinados a ser utilizados.

En términos generales, la primera forma es más popular en general porque aquellos con conocimientos previos de programación pueden fácilmente pasar a PHP y realizar el trabajo de manera orientada a objetos. La primera forma es más universal. Mi consejo sería seguir con lo que se prueba y es verdadero en muchos idiomas. Luego, cuando y si usa otro idioma, estará listo para lograr algo (en lugar de perder tiempo reinventando la rueda ).

Hay muchas formas de crear código fuente en una convención netbeans. Esto es bonito. Hace pensar que es más fácil === FALSO. Simplemente use el tradicional, especialmente si no está seguro de cuál de las propiedades debe encapsularse y cuál no. Lo sé, es un código boi .... pla ..., pero para trabajos de depuración y muchos otros piensan que es la mejor manera, clara. No pase mucho tiempo con miles de artes cómo hacer captadores y colocadores simples. No puede implementar también algunos patrones de diseño como la regla demeter y así sucesivamente, si usa magia. En una situación específica, puede usar magic_calls o para soluciones pequeñas, rápidas y claras. Claro que también podría hacer soluciones para patrones de diseño de esta manera, pero por qué hacer que su vida sea más difícil.

Validar + formatear / derivar valores

Los setters le permiten validar datos y los getters le permiten formatear o derivar datos. Los objetos le permiten encapsular datos y su código de validación y formato en un paquete ordenado que fomenta DRY.

Por ejemplo, considere la siguiente clase simple que contiene una fecha de nacimiento.

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;
    }
}

Deberá validar que el valor establecido sea

• Una fecha valida
• No en el futuro

Y no desea hacer esta validación en toda su aplicación (o en múltiples aplicaciones para el caso). En cambio, es más fácil hacer que la variable miembro esté protegida o privada (para que el configurador sea el único punto de acceso) y validar en el configurador porque entonces sabrá que el objeto contiene una fecha de nacimiento válida, sin importar qué parte del aplicación del objeto proviene y si desea agregar más validación, puede agregarlo en un solo lugar.

Es posible que desee agregar varios formateadores que operan en la misma, es decir variable miembro getAge()y getDaysUntilBirthday()y es posible que desee hacer cumplir un formato configurable getBirthDate()según la zona. Por lo tanto, prefiero el acceso consistentemente valores a través de captadores en lugar de mezclar $date->getAge()con $date->birth_date.

getters y setters también son útiles cuando extiendes objetos. Por ejemplo, suponga que su solicitud necesita permitir fechas de nacimiento de más de 150 años en algunos lugares pero no en otros. Una forma de resolver el problema sin repetir ningún código sería extender el BirthDateobjeto y colocar la validación adicional en el setter.

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);
    }
}

Este post no es específicamente sobre __gety __setsino __callque es la misma idea, excepto para llamadas de método. Como regla general, me mantengo alejado de cualquier tipo de método mágico que permita la sobrecarga por las razones descritas en los comentarios y publicaciones SIN EMBARGO , recientemente me encontré con una API de terceros que uso que utiliza un SERVICIO y un SUBSERVICIO, por ejemplo :

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

La parte importante de esto es que esta API tiene todo lo mismo excepto la sub-acción, en este caso doActionOne. La idea es que el desarrollador (yo y otras personas que usen esta clase) podría llamar al subservicio por su nombre en lugar de algo como:

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

Podría hacer en su lugar:

 $myClass->doActionOne($args);

Para codificar no sería más que una gran cantidad de duplicación (este ejemplo esta muy asemeja vagamente el código):

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();
    }

Pero con el método mágico de __call()puedo acceder a todos los servicios con métodos dinámicos:

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

El beneficio de esta llamada dinámica para la devolución de datos es que si el proveedor agrega otro subservicio, no tengo que agregar otro método a la clase o crear una clase extendida, etc. No estoy seguro de si esto es útil para nadie, pero pensé que podría mostrar un ejemplo donde __set, __get, __call, etc. puede ser una opción para su consideración ya que la función principal es la devolución de datos.

EDITAR:

Casualmente, vi esto unos días después de la publicación, que describe exactamente mi escenario. No es la API a la que me refería, pero la aplicación de los métodos es idéntica:

¿Estoy usando la API correctamente?

Actualización: No use esta respuesta ya que este es un código muy tonto que encontré mientras aprendía. Simplemente use getter y setter simples, es mucho mejor.

Por lo general, uso ese nombre de variable como nombre de función, y agrego un parámetro opcional a esa función para que cuando el llamante complete ese parámetro opcional, luego lo establezca en la propiedad y devuelva $ este objeto (encadenamiento) y luego cuando ese parámetro opcional no se especifica por persona que llama, acabo de devolver la propiedad a la persona que llama.

Mi ejemplo:

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;
          }
     }
}