2009-07-08 13 views
5

¿No se opone la inicialización fuera de una encapsulación de ruptura del constructor?Opciones de inicialización del objeto C#

dado:

class MyClass 
{ 
    public string _aString; 
} 

¿No debería ser el miembro _aString privado y instanciado a través de una llamada al constructor (constructor omitido aquí):

MyClass test = new MyClass("test"); 

En lugar del método alternativo de inicialización de objetos :

MyClass test = new MyClass { _aString = "Test" }; 
+0

¡Guau! 5 respuestas en muy poco tiempo! Gracias a todos. Este código proviene de un libro sobre C#. Tenía curiosidad sobre si se trataba de las mejores prácticas. –

Respuesta

6

"¿No se opone la inicialización fuera de una encapsulación de ruptura del constructor?"

Bueno, no. Como señaló correctamente, solo puede inicializar propiedades que ya están disponibles en su alcance actual. (público, interno, etc.)

Este tipo de Intialization es realmente solo un poco de azúcar sintáctico en torno a la construcción de una clase y la asignación de valores a las propiedades, es muy útil para las clases anónimas y las cláusulas de selección de Linq.

5

Por lo general, se considera una mala práctica exponer al público. campos ... puede ser aceptable en algunos casos, por ejemplo, si el campo está marcado como readonly (lo que significa que debe establecerse en el constructor). En su lugar, usted debe hacer este campo privado y exponerlo a través de una propiedad, que pueden o no ser de sólo lectura, dependiendo de su propósito:

class MyClass 
{ 
    private string _aString; 
    public string AString 
    { 
     get { return _aString; } 
     // uncomment to make the property writable 
     //set { _aString = value; } 
    } 
} 
0

Depende del propósito de la variable. Si el programador solo pudiera establecer la variable en la inicialización, pero luego no tener acceso a ella después de eso, entonces iría con la variable privada. Si desea que el usuario de la clase pueda establecer/leer la variable en cualquier momento, hágalo público.

0

Cuando se tiene
public string _aString;
que realmente no importa al inicializar este valor puesto que esto ya está expuesto. Entonces, cuando queremos hablar sobre la inicialización, debemos mover esta cadena a la propiedad. Que hablar sobre la encapsulación tiene sentido.
Entonces, imagina que tenemos algo de cadena. Hay dos enfoques para la inicialización. Una es hacerlo dentro del constructor, la segunda es la inicialización lenta (inicializar cuando algunos soliciten esta información).

0

sí, inicialícese a través del constructor y agregue propiedades para permitir (o no) el acceso a los datos.

class MyClass { 
private string _aString; 
string MyProperty { 
        get { return this._aString; } 
        // you can make this private or protected 
        set { this._aString = value; } 

        } 
} 
1

Si considera propiedades como getters y setters, no creo que rompa la encapsulación. Pero debes notar que no usaste una propiedad, has usado una variable de instancia. De hecho, no creo que funcione como tu ejemplo. Verifique esto:

class MyClass { 
    private string aString; 

    public string AString { 
     get { return aString; } 
     set {aString = value; } 
    } 
} 
MyClass test = new MyClass { 
    AString = "test" 
}; 

En este caso, está accediendo al campo privado a través de su acceso. Es como usar un constructor sin parámetros y establecer el valor más tarde.

+1

El establecimiento de campos públicos directamente es a-ok en los inicializadores de objetos (desde el punto de vista de la semántica del lenguaje, no el diseño apropiado). –

+0

¡Eso no lo sabía! ¡Gracias! = D – Fernando

0

Si está preguntando si la nueva abreviatura de inicialización de objeto rompe la encapsulación, la respuesta es no. Solo puede establecer miembros de ámbito público con el nuevo método.

MyClass test = new MyClass { _aString = "Test" }; 

es lo mismo que

MyClass test = new MyClass(); 
test._aString = "Test"; 
0

Para mostrar un público objeto en una clase C# no se rompe "encapsulación" desde un punto de vista de la "programación orientada a objetos".

Desde el punto de vista de una "buena práctica" no es algo bueno, use Propiedades porque permite que el código externo use esta clase si cambia el comportamiento de actualización de este valor (verificando, ...).

Cuestiones relacionadas