java - son - ¿Cómo accedería a las propiedades del Objeto desde un método de objeto?




recibir un objeto en java (12)

¿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 afuera del objeto deberías usar un captador / setter, pero desde adentro solo harías:

Java:

String property = this.property;

PHP:

$property = $this->property;

o harías:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Perdóname si mi Java está un poco apagado, ha pasado un año desde que programé en Java ...

EDITAR:

Parece que la gente asume que estoy hablando solo de variables / propiedades privadas o protegidas. Cuando aprendí OO, me enseñaron a usar getters / setters para cada propiedad, incluso si era pública (y en realidad me dijeron que nunca hiciera pública ninguna variable / propiedad). Por lo tanto, puedo comenzar desde una suposición falsa desde el principio. Parece que las personas que responden a esta pregunta tal vez dicen que debería tener propiedades públicas y que no necesitan captadores y colocadores, 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 ...


¿Estoy yendo por la borda aquí?

Quizás ;)

Otro enfoque sería utilizar un método privado / protegido para hacer realmente la obtención (almacenamiento en caché / db / etc.), y un contenedor público para ello 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 manera, todavía puede usar ese primer argumento para otra cosa (como enviar una bandera para saber si usar o no los datos en caché aquí, tal vez).


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

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


Como se indica en algunos de los comentarios: a veces deberías, a veces no deberías. La gran 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.

Podría darse el caso opuesto de que si usa el captador / configurador y alguien cambia el captador / definidor, tienen que analizar todos los lugares en los que el captador y el configurador se utilizan internamente para ver si ensucia algo.


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

Tomando esto a su conclusión, el getter debería llamar a un getter, que debería llamar a un getter.

Entonces, diría que dentro de un método de objeto acceder a una propiedad directamente, especialmente ver como llamar a otro método en ese objeto (que simplemente accederá a la propiedad directamente de todos modos y luego lo devolverá) es solo un ejercicio inútil y derrochador (o he entendido mal la pregunta )


Depende. Es más un problema de estilo que otra cosa, y no hay una regla estricta.


Descubrí que usar setters / getters hizo que mi código fuera 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á.


Estoy bastante sorprendido de cuán unánime es el sentimiento de que los getters y los colocadores están bien y son buenos. Sugiero el artículo incendiario de Allen Holub " Getters And Setters Are Evil ". De acuerdo, el título es para el valor de choque, pero el autor hace puntos válidos.

Esencialmente, si tiene getters y establecedores para cada campo privado, está haciendo que esos campos sean tan públicos. Sería muy difícil cambiar el tipo de campo privado sin efectos dominó para cada clase que llame a ese getter .

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

Los captadores y establecedores también alientan a los usuarios de la clase a pedir algunos datos al objeto, realizar un cálculo y luego establecer algún otro valor en el objeto, mejor conocido como programación de procedimientos. Será mejor que simplemente le diga al objeto que haga lo que iba a hacer en primer lugar; también conocido como el modismo experto en información .

Los getters y setters, sin embargo, son males necesarios en el límite de las capas: interfaz de usuario, persistencia, etc. El acceso restringido a las partes internas de una clase, como la palabra clave friend de C ++, el acceso protegido del paquete de Java, el acceso interno de .NET y el patrón de clase Friend puede ayudarlo a reducir la visibilidad de los getters y setters solo para aquellos que los necesitan.


La manera purista de OO es evitar ambos y seguir la Ley de Demeter utilizando el enfoque Tell Don't Ask .

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

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

Cuando la propiedad era de tipo nativo, por ejemplo, int, use un método de acceso, asígnele el nombre del dominio del problema, no del 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 condición previa o invariantes dependientes, sin embargo, no caiga en la trampa de nombrarlos setters, vuelva al Principio de Hollywood para nombrar cuando use el idioma.


PHP ofrece una infinidad de formas de manejar esto, incluidos los métodos mágicos __get y __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 el caso)
  2. Intellisense funciona con métodos explícitos.
  3. No hay duda 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 queda sin documentar

Personalmente, siento que es importante permanecer constante. Si tienes captadores y colocadores, úsalos. La única vez que accedería a un campo directamente es cuando el descriptor de acceso tiene mucha sobrecarga. Puede parecer que está inflando su código innecesariamente, pero ciertamente puede ahorrarle mucho dolor de cabeza en el futuro. El ejemplo clásico:

Más adelante, es posible que desee cambiar la forma en que funciona ese campo. Tal vez debería calcularse sobre la marcha o tal vez desee utilizar 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 de una sola vez.


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

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


Si por "purista" te refieres a "la mayoría de la encapsulación", entonces típicamente declaro que todos mis campos son privados y luego uso this.field desde dentro de la propia clase, pero todas las demás clases, incluidas las subclases, acceden al estado de instancia utilizando los captadores.





theory