¿Cuándo debería una clase usar sus propios getters/setters frente a acceder directamente a los miembros?

Question

Al generar setters y getters en Eclipse, una de las opciones es utilizar getters y setters dentro de la clase en lugar de acceder directamente a los miembros de la clase. ¿Es útil este nivel de encapsulación interna o está llevando una buena idea un paso demasiado lejos?

DUPE: Should you use accessor properties from within the class, or just from outside of the class?

Answer 1

Creo que es una buena idea si desea que los posibles efectos secundarios que se produzca - validación, registro, etc. (En C# Me gustaría ser capaz de declarar una variable y propiedad y decir que la única acceso a la variable es a través de la propiedad.)

en ocasiones, puede así encontrar lo que necesita para establecer la variable directamente, precisamente porque no lo hace quiere que los efectos secundarios. Por ejemplo, es posible que necesite establecer dos variables juntas, y los estados "antes" y "después" son válidos, pero establecer cualquiera de las propiedades individualmente haría que la validación explotara.

Answer 2

Puede ser útil, si permite que las clases derivadas vuelvan a definir sus captadores. Por lo tanto, usar getters incluso desde dentro de la clase mantendrá su diseño extensible.

En mi opinión, esto es algo que debe definirse en las directrices de codificación.

Answer 3

Es útil, por ejemplo, cuando tiene instaladores que realizan acciones adicionales, como configurar una bandera sucia o notificar a los observadores.

En vez de acceder a un campo, el usuario puede calcular un valor cuando cambia la representación.

Answer 4

Me parece que hago eso a veces, específicamente cuando requiero, o anticipo fuertemente que necesitaré, algunos inicios de sesión para obtener o configurar (y la validación de los mismos) de los miembros.

Creo que tener propiedades privadas/internas ayuda en estos casos.

Pero ciertamente no lo hago para ningún memeber.

reciente .NET/VS realmente ayuda aquí como se puede declarar una propiedad como tal:

public string SomeProperty 
{ 
get; 
set; 
} 

y crea efectivamente la memebr detrás de la escena. Sé que eso no te ayuda, pero pensé que podría ser de tu interés :-)

Answer 5

Si quieres que este miembro sea databindable con Winform o WPF, creo que debes declararlo como un propiedad. Soy aproximadamente un 95 por ciento positivo de que la unión de datos requiere una propiedad (sintaxis getter/setting). Tengo una solución de wpf pequeña que demuestra esto, pero no veo la manera de adjuntarlo aquí.

Aquí está el código: (creado con VS 2008 SP1, orientación .net 3.5 - Usé un proyecto de WPF). Hay 2 elementos en el proyecto WPF, la ventana principal (ventana1) y el objeto que estamos probando (DataObject) Hay una etiqueta en la ventana que está vinculada a la propiedad Name en una instancia de objeto de datos. Si convierte la propiedad Name a un campo (elimina el getter/setter), el enlace de datos dejará de funcionar.

Ventana1.xaml:

<Window x:Class="WpfDatabinding.Window1" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Title="Window1" Height="300" Width="300"> 
<Grid> 
    <Label Name ="Label1" Height="28" Margin="12,24,37,0" VerticalAlignment="Top" Content="{Binding Name}"></Label> 
</Grid> 

Window1.xaml.cs

using System; 
using System.Windows; 

namespace WpfDatabinding 
{ 
    /// <summary> 
    /// Interaction logic for Window1.xaml 
    /// </summary> 
    public partial class Window1 : Window 
    { 
     private DataObject ADataObject; 

     public Window1() 
     { 
      InitializeComponent(); 
      this.ADataObject = new DataObject(); 
      this.ADataObject.Name = "Hello!"; 
      this.DataContext = this.ADataObject; 
     } 
    } 
} 

namespace WpfDatabinding 
{ 
    /// <summary> 
    /// Interaction logic for Window1.xaml 
    /// </summary> 
    public partial class Window1 : Window 
    { 
     private DataObject ADataObject; 

     public Window1() 
     { 
      InitializeComponent(); 
      this.ADataObject = new DataObject(); 
      this.ADataObject.Name = "Hello!"; 
      this.DataContext = this.ADataObject; 
     } 
    } 
} 

DataObject.cs:

namespace WpfDatabinding 
{ 
    public class DataObject 
    { 
     // convert this to a field, and databinding will stop working 
     public string Name 
     { 
      get; 
      set; 
     } 
    } 
} 

Answer 6

La respuesta corta es "depende" :)

Eric Lippert tiene un excelente artículo sobre Automatic vs. Explicit properties que trata este problema, aunque desde un ángulo ligeramente diferente.

En esencia, la pregunta que hay que preguntarse es:

"Desde dentro de la clase, [son] la semántica deseados de acceso a esta propiedad ... diferentes a la semántica deseados de acceso a la propiedad de la ¿fuera de?"

Si la semántica es la misma, su clase debe usar sus propias propiedades. Si la semántica es diferente, su clase necesitará manipular directamente los campos de respaldo.

Answer 7

Cuando necesite extender el comportamiento getter/setter de una clase, es útil tener campos encapsulados (getters/setters en lugar de acceso directo a miembros). Sin embargo, en la herencia, es conceptualmente interesante preservar los interiores de su clase, si sus subclases no deberían estar al tanto de sus asuntos privados. Por lo tanto, a veces el campo es privado para la implementación de una clase, por lo que incluso las subclases no son conscientes de ello.