C # protegida campo para privados, añadir una propiedad - por qué?

Question

En 2008 Team System Visual Studio, que acaba de ejecutar el análisis de código (en el menú Analizar) en uno de mis proyectos de C #. Una de las advertencias producido fue la siguiente:

  

Microsoft.Design:. Debido a que el campo 'Connection._domain' es visible fuera de su tipo que se declara, cambiar su accesibilidad a privada y añadir una propiedad, con la accesibilidad mismo que el campo tiene actualmente, para proporcionar acceso a ella

Se hace referencia al campo siguiente:

public abstract class Connection
{
    protected string _domain;
}

No entiendo el razonamiento detrás de la sugerencia. Esto es lo que creo que quiere que haga:

public abstract class Connection
{
    private string _domain;
    protected string Domain { get { return _domain; } set { _domain = value; } }
}

Dos preguntas:

1. ¿He entendido bien lo que la sugerencia quiere que haga, código-sabio?
2. ¿Por qué quiere que haga esto?

Answer 1

Sí, creo entendido bien - aunque en versiones posteriores de C #, hay una manera más concisa para escribirlo:

public string Domain { get; set; }

¿Por qué? Es todo acerca de la encapsulación. Si lo hace, ya que sugiere, más tarde puede cambiar la definición de la propiedad de dominio sin afectar a ningún código de llamada que utiliza esa propiedad. Dado que la clase es pública, y podría concebiblemente ser llamado por el código que usted no escribió, eso es potencialmente muy importante.

Answer 2

Sí. Esa es la sugerencia. Usted no debe tener ningún acceso privado más alta que se expone como campos de instancia directos.

Es uno de los principios fundamentales de OOD -. Encapsulación también se conoce como 'técnica de ocultación'

Answer 3

1. Sí, es cierto correcta el código de problema sabia.
2. Se trata de encapsulación. _domain incluye datos acerca del objeto. En lugar de exponerlo directamente para que cualquier cliente tiene acceso sin filtros, usted debe proporcionar una interfaz para que puedan acceder a ella. Prácticamente esto podría ser la adición de validación para el colocador de modo que no se puede ajustar a cualquier valor. Puede parecer tonto si usted es el único código de una escritura porque usted sabe cómo funciona su API. Pero tratar de pensar en las cosas a nivel de las grandes empresas, es mejor tener una API para que su objeto puede ser visto como una caja que accomiplishes una tarea. Se podría decir que nunca tendrá la necesidad de añadir algo así como la validación de ese objeto, pero las cosas se hacen de esa manera para mantener la posibilidad de que, además de ser coherente.

Answer 4

Su traducción es correcta. El mismo argumento para puede ser hecho para el uso de propiedades de 'protegidas' como puede ser hecho para el uso de propiedades de 'públicas' en lugar de exponer las variables miembro directamente.

Si esto sólo conduce a una proliferación de captadores y definidores simples a continuación, creo que el daño a la mejor legibilidad de código mayor que el beneficio de ser capaz de cambiar el código en el futuro. Con el desarrollo de propiedades generados por el compilador de C # esto no es tan malo, sólo tiene que utilizar:

protected string Domain { get; set; }

Answer 5

Esto se debe a que si alguna vez quería cambiar el campo a una propiedad en el futuro usted se rompería cualquier otro montajes que dependen de ella.

Es una buena práctica para mantener todos los ámbitos privado y envolverlos en propiedades para que usted tiene la opción de añadir la validación u otra lógica en el futuro sin tener que recompilar todos los consumidores (o en este caso herederos) de su clase.

Answer 6

En respuesta a su pregunta ... sí.

Sin embargo, me gustaría simplemente utilizar la sintaxis de auto-propiedad:

public abstract class Connection
{
    protected string Domain { get; set; }
}

Answer 7

Básicamente, propiedades proporcionan más de devolución o el establecimiento de un miembro. Ellos le permiten añadir lógica que pudo comprobar un formato de entrada adecuada, validación gama, etc.

La respuesta seleccionada del enlace pone mejor, "Las propiedades proporcionan encapsulación. Puede encapulate ninguna validación / formatear / conversión necesaria para el código de la propiedad. Esto sería difícil de hacer para los campos."

http: / /social.msdn.microsoft.com/Forums/en-IE/netfxbcl/thread/985f4887-92ae-4ec2-b7ae-ec8cc6eb3a42

Answer 8

Además de las otras respuestas que se mencionan aquí, los miembros públicos / protegidas que comienzan con un carácter de subrayado no son compatible con CLS , en la que no hay ningún requisito para lenguajes .NET para apoyar a los miembros con subrayado iniciales, por lo que alguien que hereda de la clase en un lenguaje .NET diferente puede no ser capaz de acceder a esa particular miembro protegido.

Lo sé, es probable que no se aplica a usted, pero podría ser parte de la razón por la advertencia de análisis de código.