¿Cómo accedería a las propiedades de Objeto desde dentro de un método de objeto?

votos
81

¿Cuál es la forma purista o correcta de acceder a las propiedades de un objeto desde un método de objeto que no es un método getter / setter?

Sé que desde fuera del objeto debes usar un getter / setter, pero desde dentro lo harías:

Java:

String property = this.property;

PHP:

$property = $this->property;

o lo harías:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Perdóname si mi Java está un poco mal, hace un año que programé en Java ...

EDITAR:

Parece que las personas están asumiendo que estoy hablando solo de variables / propiedades privadas o protegidas. Cuando aprendí OO, me enseñaron a utilizar getters / setters para cada propiedad, incluso si era pública (y en realidad me dijeron que nunca publicara ninguna propiedad / variable). Entonces, puedo partir de una suposición falsa desde el principio. Parece que las personas que responden a esta pregunta quizás dicen que deben tener propiedades públicas y que no necesitan getters y setters, lo que va en contra de lo que me enseñaron, y de lo que estaba hablando, aunque tal vez eso deba discutirse como bien. Sin embargo, ese es probablemente un buen tema para una pregunta diferente ...

Publicado el 01/08/2008 a las 17:10
fuente por usuario
En otros idiomas...                            


18 respuestas

votos
58

Esto tiene un potencial de guerra religiosa, pero me parece que si estás usando un getter / setter, deberías usarlo también internamente - usar ambos llevará a problemas de mantenimiento en el futuro (por ejemplo, alguien agrega código a un setter que necesita para ejecutar cada vez que se establece una propiedad, y la propiedad se establece internamente sin que se llame al setter).

Respondida el 01/08/2008 a las 17:13
fuente por usuario

votos
41

Personalmente, siento que es importante permanecer constante. Si tiene getters y setters, úselos. La única vez que accedería directamente a un campo es cuando el acceso tiene mucha sobrecarga. Puede parecer que está inflando su código innecesariamente, pero ciertamente puede ahorrar un montón de dolores de cabeza en el futuro. El ejemplo clásico:

Más adelante, puede desear cambiar la forma en que funciona el campo. Tal vez debería calcularse sobre la marcha o tal vez le gustaría usar un tipo diferente para la tienda de respaldo. Si está accediendo a las propiedades directamente, un cambio como ese puede romper una gran cantidad de código en un solo caso.

Respondida el 01/08/2008 a las 19:23
fuente por usuario

votos
25

Estoy bastante sorprendido de cuán unánime es la opinión de que los getterssetters están bien y están bien. Sugiero el artículo incendiario de Allen Holub " Getters And Setters Are Evil ". De acuerdo, el título es para el valor de shock, pero el autor hace puntos válidos.

Esencialmente, si tiene gettersy setterspara cada campo privado, está haciendo esos campos tan buenos como públicos. Sería muy difícil cambiar el tipo de campo privado sin efectos dominantes a todas las clases que lo llamen getter.

Además, desde un punto de vista estrictamente OO, los objetos deberían responder a los mensajes (métodos) que corresponden a su (única) responsabilidad (afortunadamente). La gran mayoría de gettersy settersno tienen sentido para sus objetos constituyentes; Pen.dispenseInkOnto(Surface)tiene más sentido para mí que Pen.getColor().

Getters y setters también alientan a los usuarios de la clase a pedir al objeto algunos datos, realizar un cálculo y luego establecer algún otro valor en el objeto, mejor conocido como programación de procedimientos. Sería mejor que simplemente dijeras al objeto que hicieras lo que ibas a hacer en primer lugar; también conocido como el idioma de Information Expert .

Sin embargo, los captadores y setters son males necesarios en el límite de las capas: IU, persistencia, etc. El acceso restringido a las partes internas de una clase, como la palabra clave de amigo de C ++, el acceso protegido de paquetes de Java, el acceso interno de .NET y el patrón de clase de amigos pueden ayudarlo a reducir la visibilidad de los gettersinstaladores solo a quienes los necesitan.

Respondida el 19/09/2008 a las 01:13
fuente por usuario

votos
18

Depende de cómo se usa la propiedad. Por ejemplo, supongamos que tiene un objeto de estudiante que tiene una propiedad de nombre. Puede usar su método Get para extraer el nombre de la base de datos, si aún no se ha recuperado. De esta forma estás reduciendo llamadas innecesarias a la base de datos.

Ahora digamos que tiene un contador de enteros privado en su objeto que cuenta la cantidad de veces que se ha llamado su nombre. Es posible que no desee utilizar el método Get desde el interior del objeto, ya que produciría un recuento no válido.

Respondida el 01/08/2008 a las 17:19
fuente por usuario

votos
13

PHP ofrece una gran variedad de formas de manejar esto, incluidos los métodos mágicos __gety __set, pero prefiero getters y setters explícitos. Este es el por qué:

  1. La validación se puede colocar en setters (y getters para ese asunto)
  2. Intellisense funciona con métodos explícitos
  3. No hay dudas de si una propiedad es de solo lectura, solo escritura o lectura-escritura
  4. La recuperación de propiedades virtuales (es decir, valores calculados) tiene el mismo aspecto que las propiedades normales
  5. Puede establecer fácilmente una propiedad de objeto que nunca se define realmente en ningún lugar, que luego se convierte en no documentada
Respondida el 24/09/2008 a las 18:24
fuente por usuario

votos
12

¿Estoy yendo por la borda aquí?

Quizás ;)

Otro enfoque sería utilizar un método privado / protegido para hacer realmente el get (caching / db / etc), y un contenedor público que incremente el recuento:

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

y luego desde dentro del objeto mismo:

PHP:

$name = $this->_getName();

De esta forma, aún puede usar ese primer argumento para otra cosa (como enviar una marca para que se utilicen o no los datos en caché).

Respondida el 01/08/2008 a las 17:43
fuente por usuario

votos
11

Debo estar perdiendo el punto aquí, ¿para qué usar un captador dentro de un objeto para tener acceso a una propiedad de ese objeto?

Tomando esto a su conclusión, el comprador debe llamar a un comprador, que debe llamar a un captador.

Así que yo diría que dentro de un método de objeto de acceso de un inmueble directamente, sobre todo viendo como llamar a otro método en el que el objeto (que se acaba de acceder a la propiedad directa de todos modos luego devolverlo) es sólo un ejercicio inútil, derrochador (o he entendido mal la pregunta ).

Respondida el 04/06/2011 a las 16:42
fuente por usuario

votos
7

Yo diría que es mejor utilizar los métodos de acceso, incluso dentro del objeto. Estos son los puntos que vienen a la mente de inmediato:

1) Se debe hacer en el interés de mantener la coherencia con accesos realizados fuera del objeto.

2) En algunos casos, estos métodos de acceso podrían estar haciendo algo más que el acceso a la materia; que podrían estar haciendo algún tipo de procesamiento adicional (aunque su rara). Si este es el caso, mediante el acceso al campo directamente a usted le faltan a cabo esta transformación adicional y su programa podría ir mal si este tratamiento es siempre hay que hacer durante esos accesos

Respondida el 20/01/2010 a las 09:32
fuente por usuario

votos
7

La forma purista de OO es evitar ambas y seguir la Ley de Demeter usando el enfoque Tell Do not Ask .

En lugar de obtener el valor de la propiedad del objeto, que combina estrechamente las dos clases, use el objeto como parámetro, por ejemplo

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

Donde la propiedad era de tipo nativo, por ejemplo, int, usa un método de acceso, nómbralo para el dominio del problema, no para el dominio de programación.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Esto le permitirá mantener la encapsulación y cualquier condición posterior o invariantes dependientes. También puede usar el método setter para mantener cualquier precondición o invariante dependiente, sin embargo, no caiga en la trampa de nombrarlos setters, regrese al Principio de Hollywood para nombrarlos cuando use la expresión idiomática.

Respondida el 24/09/2008 a las 18:04
fuente por usuario

votos
7

Si por "purista" quiere decir "más encapsulación", entonces generalmente declaro todos mis campos como privados y luego uso este campo desde dentro de la clase misma, pero todas las demás clases, incluidas las subclases, acceden al estado de instancia utilizando los getters.

Respondida el 22/08/2008 a las 12:15
fuente por usuario

votos
6

Depende. Es más un problema de estilo que cualquier otra cosa, y no hay una regla rígida.

Respondida el 01/10/2008 a las 11:51
fuente por usuario

votos
6

Si no voy a editar la propiedad, get_property()usaré un método público a menos que sea una ocasión especial, como un objeto MySQLi dentro de otro objeto, en cuyo caso solo publicaré la propiedad y me referiré a ella como $obj->object_property.

Dentro del objeto siempre es $ this-> propiedad para mí.

Respondida el 22/08/2008 a las 12:34
fuente por usuario

votos
6

Campos privados con propiedades públicas o protegidas. El acceso a los valores debe pasar por las propiedades y copiarse a una variable local si se usarán más de una vez en un método. Si y ÚNICAMENTE si tiene el resto de su aplicación totalmente ajustada, mecedora y optimizada para que el acceso a los valores pasando por sus propiedades asociadas se haya convertido en un cuello de botella (Y eso nunca sucederá, lo garantizo) incluso si usted comienza considerar permitir que cualquier cosa que no sea las propiedades toque directamente sus variables de respaldo.

Los desarrolladores de .NET pueden usar propiedades automáticas para imponer esto, ya que ni siquiera puede ver las variables de respaldo en tiempo de diseño.

Respondida el 18/08/2008 a las 18:43
fuente por usuario

votos
6

He descubierto que usar setters / getters hizo que mi código sea más fácil de leer. También me gusta el control que da cuando otras clases usan los métodos y si cambio los datos, la propiedad se almacenará.

Respondida el 18/08/2008 a las 18:37
fuente por usuario

votos
6

Puedo estar equivocado porque soy autodidacta, pero NUNCA uso propiedades públicas en mis clases de Java, siempre son privadas o están protegidas, por lo que el código externo debe tener acceso por getters / setters. Es mejor para fines de mantenimiento / modificación. Y para el código de clase interno ... Si el método getter es trivial, uso la propiedad directamente, pero siempre utilizo los métodos setter porque podría agregar código fácilmente a eventos de fuego si lo deseo.

Respondida el 06/08/2008 a las 15:43
fuente por usuario

votos
5

Me gusta la respuesta de cmcculloh , pero parece que la respuesta más acertada es la de Greg Hurlman . Use getter / setters todo el tiempo si comenzó a usarlos desde el getgo y / o está acostumbrado a trabajar con ellos.

Como comentario aparte, personalmente encuentro que el uso de getter / setters hace que el código sea más fácil de leer y depurar más adelante.

Respondida el 15/09/2008 a las 10:46
fuente por usuario

votos
5

Bueno, parece que con la implementación predeterminada de las propiedades de C # 3.0, la decisión se toma por usted; TIENE que establecer la propiedad utilizando el ajustador de propiedades (posiblemente privado).

Personalmente, solo uso el miembro privado detrás cuando no hacerlo podría hacer que el objeto caiga en un estado menos que deseable, como cuando se inicializa o cuando está involucrado el almacenamiento en caché / carga lenta.

Respondida el 01/08/2008 a las 17:56
fuente por usuario

votos
4

Como se afirma en algunos de los comentarios: A veces deberías, a veces no deberías. La mejor parte de las variables privadas es que puedes ver todos los lugares donde se usan cuando cambias algo. Si su getter / setter hace algo que necesita, úselo. Si no importa, tú decides.

El caso opuesto podría ser que si usas el getter / setter y alguien cambia el getter / setter tienen que analizar todos los lugares en los que el getter y el setter se usan internamente para ver si ensucia algo.

Respondida el 01/08/2008 a las 18:01
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more