Classe immutabile con comportamento

Question

Classe immutabile con comportamento

#1 da (5 voti)

0

Ho appena finito Java efficace e l'ho adorato. Sto cercando di ridefinire uno dei miei programmi per trarre vantaggio da ciò che ho imparato, e ho un sacco di domande riguardo l'immutabilità.

Il mio programma è in gran parte costruito attorno a una classe del modello che rappresenta un promemoria, che è memorizzato in un fornitore di contenuti. Questo articolo suggerisce che, poiché rappresenta i dati contenuti nel fornitore di contenuti, potrei creare una classe immutabile che chiama semplicemente al fornitore di contenuti. Ma per quanto ne so, questo autore ha torto e questa è una pessima idea. A me sembra che sarebbe molto imprevedibile chiamare il fornitore di contenuti tutto il tempo, che quindi interroga un database SQLite, e non sono incline a seguire questo modello.

La mia altra domanda riguarda diverse piccole classi che ho dove nessuno dei loro membri cambia dopo che sono stati creati, ma fanno chiamate asincrone ai servizi di sistema e restituiscono la risposta lungo un'interfaccia. Una classe del genere può essere immutabile? La classe stessa è stateless e non cambia mai una volta creata, ma chiama altre classi strettamente legate allo stato del dispositivo.

immutability java performance

posta TBridges42 31.07.2015 - 01:29

fonte

1 risposta

Leggi altre domande sui tag immutability java performance

Esiste una funzione di comparazione delle stringhe approssimativa che è dispari come le funzioni matematiche sono dispari? Alternative alla richiesta di commenti

score 5 · Accepted Answer

Per favore non seguire il consiglio in quell'articolo.

L'autore è corretto per difendere oggetti immutabili. Ma per ottenere i vantaggi degli oggetti immutabili, l'oggetto dovrebbe essere transitivamente immutabile. Cioè, dovrebbe solo mantenere riferimenti ad altri oggetti transitivamente immutabili. Non dovrebbe fare riferimento ai fornitori di dati, e certamente non dovrebbe mantenere il suo stato su qualche altro oggetto in un tentativo fuorviante di fingere di essere immutabile quando non lo è.

Gli oggetti immutabili sono belli soprattutto perché sono facili da ragionare. So che una volta creati non cambiano. Se è lo stesso oggetto di prima, so che nulla è diverso. So che posso passarle altre funzioni e non preoccuparmi che cambino.

La soluzione proposta in quell'articolo rende l'oggetto apparentemente immutabile atto come un oggetto mutabile. Certo, potrebbe non modificare effettivamente i propri campi, ma si comporta ancora come un oggetto mutevole. Non mi interessa davvero come viene implementato internamente, è un prodotto mutabile a tutti gli effetti.

Quindi, sì, dal mio punto di vista quel sito è pieno di idee terribili. Non sarebbe performante e non avrebbe quasi nessuno dei vantaggi degli oggetti immutabili. Tutto quello che faresti è sacrificare la semplicità e l'efficienza per una comprensione sbagliata dell'immutabilità.

My other question regards several small classes I have where none of their members change after they are created, but they make asynchronous calls to system services, and return the response along an interface. Can a class like that ever be immutable? The class itself is stateless and never changes once created, but it calls other classes that are closely tied to device status.

Non definirei tale classe immutabile. Sì, è immutabile in un certo senso perché non cambia. Ma questo è un dettaglio di implementazione. Non si comporta come un oggetto immutabile. Quando utilizzo questo oggetto altrove, mi interessa l'interfaccia, non l'implementazione.