Proprietà e incapsulamento

Question

Segue una domanda sull'utilizzo delle proprietà in classe.

Ho utilizzato le proprietà pubbliche invece di esporre pubblicamente le variabili membro. Maggioranza consiglia che questo approccio aiuti l'incapsulamento. Tuttavia, non capisco il vantaggio di incapsulamento rendendolo una proprietà.

molte persone non sanno il vero motivo dell'utilizzo delle proprietà. Lo fanno semplicemente come parte dello standard di codifica.

Qualcuno può spiegare chiaramente come una proprietà è migliore della variabile membro pubblico e come migliora l'incapsulamento?

Answer 1

L'incapsulamento aiuta a isolare le classi di chiamata dai cambiamenti.

Immaginiamo di avere una classe semplice che modella un motore di un'auto (perché tutti gli esempi OO dovrebbero comportare un'analogia dell'automobile :)). Si può avere un campo semplice come questo:

private bool engineRunning; 

semplicemente facendo questo campo pubblico o fornire un getter IsEngineRunning() non sembra essere diverso.

Ora supponiamo si effettua la classe più sofisticata, che si desidera rimuovere quel campo e sostituirlo con:

private bool ignitionOn; 
private bool starterWasActivated; 

Ora, se avete un sacco di classi di accesso a vecchia engineRunning campo si deve andare e cambiarli tutto (tempi brutti).

Se invece aveva iniziato con:

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

si potrebbe ora cambiare per:

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

e l'interfaccia della classe rimane la stessa (bei tempi).

Answer 2

Alcuni pensieri:

• È possibile modificare la rappresentazione interna dei dati senza compromettere le classi di chiamata.

  E.g. (prima)

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

  (dopo)

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

  Ciò è particolarmente importante se il codice viene utilizzato da altri (cioè il codice è 3rd-party). In una certa misura la tua interfaccia/API deve rimanere stabile. Piccole modifiche non dovrebbero influenzare il codice di altro codice che lo utilizza.

• È possibile avere operazioni più complesse. Considerare una variabile is_active. Forse la modifica del valore di questa variabile influenza anche altre proprietà dell'oggetto. Se incapsuli l'accesso in un metodo, puoi prenderlo in considerazione all'interno di questo metodo e il chiamante non deve preoccuparsi.

  E.g.

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

  Applica pertanto una serie di azioni. È non fare affidamento sul fatto che il chiamante esegue correttamente queste azioni. Il tuo oggetto sarà sempre in uno stato corretto.

Answer 3

Farò breve. Proprietà = flessibilità

Le proprietà sono utili per creare membri che non si desidera tenere in una classe per tutto il tempo o che sono aggregazioni/funzioni di membri esistenti.

Es. l'età può essere emesso sulla base di nascita, canSwim può essere generato da hasLimbs & & galleggia

membri Esporre la proprietà può essere utile quando si tratta di modifiche impreviste [Qualcuno ha mai prevedere tutte le richieste del cliente?] in sistemi con un database esistente.

Es. isAllowed è true quando l'utente ha più di 18 anni e viene memorizzato nella cache per le prestazioni. Il cliente desidera eseguire il servizio negli Stati Uniti e restituire false se false è chached e controllare l'età solo quando la cache è true

Answer 4

È meglio esporre le proprietà anziché le variabili membro, poiché ciò consentirebbe di eseguire tutti i tipi di controllare quando si imposta o si ottiene il valore della variabile membro.

supporre u avere una variabile membro:

private int id; 

e si dispone di una proprietà pubblica:

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