Oggetto immutabile vs mutevole come parametro restituito per il metodo di classe [chiuso]

Question

Oggetto immutabile vs mutevole come parametro restituito per il metodo di classe [chiuso]

#1 da (3 voti)
#2 da (3 voti)
#3 da (0 voti)
#4 da (0 voti)

-1

Esiste un metodo di classe (metodo statico) in cui creo e costruisco alcuni oggetti. E per riempire quell'oggetto, lo creo come oggetto mutevole.

Il mio oggetto mutabile è una sottoclasse di oggetto immutabile. Quindi posso restituirlo come tipo di super classe.

Tale oggetto è appena creato nel metodo di classe e restituisce. Non fa parte dello stato dell'oggetto o della classe.

Devo restituire l'oggetto mutabile o la copia immutabile? (quale soluzione sarà corretta nel concetto di incapsulamento )

Ad esempio c'è qualche pseudo codice:

// MutableArray is subclass of Array
MutableArray : Array;

// Another class

static (Array *)getEngineers {
   Array *employees = Array.arrayWithContentsOfResource("employees.txt");
   MutableArray *engineers = new MutableArray;
   for (Employee *employee in employees) {
      if (employee.profession == "Engineer") {
         engineers.addObject(employee)
      }    
   }
   return engineers; // should I return Array.arrayWithArray(engineers) instead of engineers ?
}

Aggiornamento:

Voglio dire, se ho un array mutabile che è un membro dell'oggetto, allora ha senso restituire una copia immutabile nel metodo getter (per fornire controllo di accesso e incapsulamento). Ma se ho un metodo come nell'esempio. Ho bisogno solo di oggetti immutabili da usare. Ma la creazione di una copia immutabile di array è operazioni aggiuntive. Ha senso renderlo immutabile?

object-oriented immutability encapsulation static-methods mutable

posta BergP 08.04.2013 - 17:24

fonte

4 risposte

3

L'incapsulamento non ha nulla a che fare con l'immutabilità. Bene, forse fa un po '. Un termine più accurato sarebbe "controllo dell'accesso". Un oggetto immutabile limita il controllo dell'accesso perché non è possibile scriverlo; puoi solo leggerlo.

Rendi gli oggetti immutabili quando li stai utilizzando in un contesto multi-thread e vuoi rendere il tuo codice più ... "deterministico". Non c'è giusto o sbagliato su questo, non "corretto" o "errato;" se non stai utilizzando più thread, probabilmente non devi preoccuparti dell'immutabilità.

Rendi immutabili gli oggetti quando vuoi garantire un accesso "sicuro" all'oggetto tramite un altro thread. Un oggetto è "sicuro" per accedere in un contesto multi-thread quando puoi garantire che un altro thread non scriverà un oggetto mentre stai provando a leggerlo. Puoi farlo con immutabilità, ma puoi anche farlo con blocchi, mutex, semafori e altri meccanismi di concorrenza.

risposta data 08.04.2013 - 17:42

fonte

0

Senza saperne di più sull'uso di questo Array mutabile / immutabile, forse un fattore da considerare è la durata della matrice. Hai intenzione di memorizzare l'oggetto Array per un uso futuro o di passarlo ad altre parti del tuo codice? Se è così, allora un oggetto immutabile potrebbe essere migliore perché riduce la possibilità di cambiare accidentalmente (o forse maliziosamente) l'array Engineer. Se questo è un uso una tantum, allora potresti essere in grado di farla franca con un array mutabile perché l'esposizione di quell'array è già minima.

risposta data 08.04.2013 - 21:31

fonte

0

La tua sottoclasse non dovrebbe violare il contratto che la super-classe ha con i suoi clienti.

Non è automaticamente true che restituisce qualcosa di mutabile quando il client si aspetta che qualcosa di immutabile violi quel contratto, ma suppongo che la super-classe restituisca qualcosa di immutabile per un motivo, e che i client quindi aspettati di avere un oggetto immutabile restituito. Quindi, a meno che tu non abbia una conoscenza specifica che in questo caso è OK, non spezzare alcun codice client basandosi sull'immutabilità - restituisci qualcosa di immutabile.

(Un esempio di cosa potrebbe andare storto - forse le classi scritte per funzionare con la super-classe non controllano mai il suo stato perché assumono che sia stata controllata alla creazione e non possono essere modificate. Quindi ottiene un'istanza della classe, e non riesce a verificare che sia attualmente in uno stato valido).

risposta data 08.04.2013 - 22:15

fonte

Leggi altre domande sui tag object-oriented immutability encapsulation static-methods mutable

In che modo Common Language Runtime migliora le prestazioni? [duplicare] Quando si dovrebbe usare var invece di dichiarare un tipo esplicito?

score 3 · Accepted Answer

se solo il tuo team sta usando questo codice nello stesso processo, allora restituirei lo stesso oggetto (oggetto mutevole). mantieni semplice e veloce. Il tuo team non cambierebbe qualcosa sugli oggetti a meno che non ne avessero bisogno, e se lo facessero avrebbero dovuto fare un'altra copia.

Anche se stavo facendo un'API non lo terrei immutabile, semplice perché l'ingegnere ha l'aspetto di un oggetto che può cambiare (come se l'oggetto avesse qualcosa di simile a Reporting o degrees-held - che può cambiare nel tempo.

Gli oggetti dovrebbero imitare il più possibile le loro controparti nel mondo reale. Alcuni attributi potrebbero essere immutabili (come la data di nascita ecc.)

Buoni documenti esterni o commenti di codice potrebbero spiegare come utilizzare l'oggetto dove richiesto