2010-05-25 26 views
5

La siguiente es una pregunta sobre el uso de propiedades en la clase.Propiedad y encapsulación

He estado utilizando propiedades públicas en lugar de exponer públicamente las variables de los miembros. La mayoría aconseja que este enfoque ayude a la encapsulación. Sin embargo, no entiendo la ventaja de la encapsulación haciéndola una propiedad.

muchas personas no conocen la verdadera razón para usar propiedades. Simplemente lo hacen como parte del estándar de codificación.

¿Alguien puede explicar claramente cómo una propiedad es mejor que una variable de miembro público y cómo mejora la encapsulación?

Respuesta

6

La encapsulación ayuda aislando las clases de llamadas de los cambios.

Imaginemos que tiene una clase simple que modela el motor de un automóvil (porque todos los ejemplos de OO deben incluir una analogía de automóvil :)). Es posible que tenga un campo simple como esto:

private bool engineRunning; 

Basta con hacer pública esta materia o proporcionar un IsEngineRunning() getter no parece ser diferente.

Ahora suponga que ha hecho la clase más sofisticada, que desea eliminar este campo y reemplazarlo con:

private bool ignitionOn; 
private bool starterWasActivated; 

Ahora bien, si usted tiene un montón de clases de acceso a la antigua engineRunning campo que tiene que ir y cambiarlos todos (malos momentos).

Si en cambio había comenzado con:

public bool IsEngineRunning() 
{ 
    return this.engineRunning; 
} 

ahora podría cambiarlo a:

public bool IsEngineRunning() 
{ 
    return ignitionOn && starterWasActivated; 
} 

y la interfaz de la clase sigue siendo el mismo (buenos tiempos).

+0

me gustaría señalar que este cambio no implica que los clientes deben ser cambiados. Solo implica que deberá exponer la propiedad EngineRunning de la misma manera y con la misma semántica que antes. La única diferencia es que cada actualización de las propiedades de encendido y arranque debería actualizar también la propiedad engineRunning. Dependiendo de las lecturas/actualizaciones más frecuentes, esto puede tener un impacto positivo o negativo en el rendimiento. –

1

Algunos pensamientos:

  • Puede cambiar la representación interna de los datos sin afectar a las clases de llamadas.

    E.g. (antes)

    public boolean isActive() { 
        return this.is_active; 
    } 
    

    (después)

    public boolean isActive() { 
        return this.is_active && this.approved && this.beforeDeadline; 
    } 
    

    Esto es especialmente importante si su código es utilizado por otros (es decir, su código es 3 ª parte). Hasta cierto punto, su interfaz/API debe permanecer estable. Los pequeños cambios no deberían afectar el código de otro código que lo usa.

  • Puede realizar operaciones más complejas. Considere una variable is_active. Quizás cambiar el valor de esta variable también afecta otras propiedades del objeto. Si encapsula el acceso en un método, puede solucionarlo dentro de este método y la persona que llama no tiene que preocuparse.

    E.g.

    public void setActive(boolean active) { 
        this.is_active = active; 
        this.startTimeout(); 
        this.updateOtherInformation(); 
    } 
    

    Por lo tanto impone una cierta serie de acciones. Usted no se basan en el hecho de que la persona que llama ejecuta estas acciones correctamente. Tu objeto siempre estará en un estado correcto.

2

Lo haré corto. Propiedades de flexibilidad =

propiedades son útiles para crear los miembros que no quiera mantener en una clase todo el tiempo o que son agregaciones/funciones de los miembros existentes.

Ej. la edad puede ser la producción basada en la fecha de nacimiento, canSwim puede generarse a partir hasLimbs & & flotadores

miembros Sacar a la luz como propiedades puede ser útil cuando se trata de cambios inesperados [¿Alguien alguna vez predecir todas las solicitudes del cliente?] en sistemas con una base de datos existente.

Ej. isAllowed es verdadero cuando el usuario tiene más de 18 años y se almacena en caché para el rendimiento. El cliente quiere ejecutar el servicio en los EE. UU. Y puede devolver falso si se configura el falso y verificar la edad solo cuando el caché es verdadero

4

Es mejor exponer propiedades en lugar de variables miembro, porque eso le permitiría hacer todo tipo de comprobando al establecer u obtener el valor de la variable miembro.

supongamos que u tiene una variable miembro:

private int id; 

y usted tiene una propiedad pública:

public int ID 
{ 
    get 
    { 
     // do something before returning 
    } 
    set 
    { 
     // do some checking here may be limits or other kind of checking 
    } 
} 
Cuestiones relacionadas