incapsulamento e informazioni nascoste in Java [duplicato]

Question

incapsulamento e informazioni nascoste in Java [duplicato]

#1 da (10 voti)
#2 da (0 voti)

0

Member variables of a class are typically hidden from the outside word (i.e., the other classes), with private access control modifier. Access to the member variables are provided via public assessor methods. This follows the principle of information hiding. That is, objects communicate with each others using well-defined interfaces (public methods). Objects are not allowed to know the implementation details of others. The implementation details are hidden or encapsulated within the class. Information hiding facilitates reuse of the class.

Ho una domanda perché impostare le variabili membro come private e accedere a queste variabili tramite il metodo pubblico è sicuro rispetto all'accesso diretto alle variabili membro con modificatore pubblico. Questi 2 modi ottengono lo stesso risultato, il che significa che entrambi cambiano i valori delle variabili membro. Qualcuno può spiegarmi più chiaramente! Grazie,

java

posta vqtuyen 09.05.2017 - 09:34

fonte

2 risposte

0

Vorrei aggiungere questo alla buona risposta di @KilianFoth

metodi getter / setter come descritto nel tuo preventivo violare principio di nascondere le informazioni .

In generale abbiamo due tipi di oggetti:

contenitori di dati puri (ovvero Oggetti valore o Oggetto trasferimento dati )

Questi oggetti non hanno alcuna logica (eccetto validazioni molto semplici). Per tali classi non vogliamo nascondere la struttura interna perché questo è ciò che sono. Potremmo accettare proprietà pubbliche qui, ma la maggior parte dei framework che trattano di VO / DTO si aspettano che abbiano metodi getter / setter.
implementazioni della logica di business

Questi oggetti implementano la logica dei tuoi programmi. Vogliamo che questo sia flessibile da usare. Pertanto abbiamo bisogno di nascondere le informazioni per loro e questo a sua volta significa che dovremmo evitare i metodi getter / setter.

risposta data 09.05.2017 - 12:07

fonte

Leggi altre domande sui tag java

Associazioni di modelli di dominio che non richiedono il comportamento dell'oggetto associato. Come modellare? Cosa rende PHP una lingua e jQuery una libreria?

score 10 · Accepted Answer

Perché nascondere le informazioni non è una misura di sicurezza. È una misura orientata all'uomo per migliorare la comprensione .

Il punto di rendere un campo privato non è di impedirne la modifica. Se un utente malintenzionato desidera modificare i valori, beh, se ha accesso al processo del proprio programma, può modificare facilmente i valori, indipendentemente dal modo in cui il codice sorgente ha definito tali valori. È tutto solo bit in memoria o in una cache da qualche parte comunque.

Allora qual è il punto? Nascondere le informazioni rende più facile ragionare sul tuo programma quando qualcun altro (o te, due mesi in giù) deve capirlo o cambiarlo. Non esponendo i campi esatti di cui è composta una classe, diventa più facile capire quale scopo serve, se usarlo o meno, quali metodi chiamare ecc. Cosa preferiresti fare: chiamare un metodo hitBrakes() o scrivere flags.frictionCoefficient &= 0x487FD3 ?

Ma questa è una grande differenza. È davvero utile una piccola differenza come quella tra car.setPrice(12345) e car.price = 12345 ? Oh si lo è. Programmando un accessorio invece di esporre un campo pubblico, ti sei dato la possibilità di cambiare l'implementazione di quell'accessorio un giorno. Forse diventa necessario includere la logica di convalida in quell'accessor, o persino renderlo inutilizzabile e conservarlo solo per compatibilità con le versioni precedenti. Con un campo pubblico, non puoi fare nulla di tutto ciò senza rompere il codice client.

E questo è il motivo per cui l'hiding delle informazioni è buono - non perché nessun altro deve non vederlo, ma perché non vuoi per vederlo. Le informazioni che non sono pubbliche non possono diventare un limite allo sviluppo futuro.