responsabilità per l'archiviazione

Preferirò la seconda opzione come segue principio di responsabilità singola , vale a dire che un oggetto dovrebbe fare solo una cosa e fare bene. Seguendo il protocollo SRP nel tuo caso assicurerai che vi sia un accoppiamento lento tra la tua funzionalità principale e il meccanismo di persistenza, in questo modo puoi modificare le specifiche del meccanismo di persistenza, ad es. puoi mantenere il tuo oggetto come XML invece del formato di file specifico, fornire la crittografia o archiviare l'oggetto su un server invece che sul tuo computer locale.

Definirei sicuramente il livello di persistenza dall'oggetto. Sembra logico che lo strato di persistenza debba essere intercambiabile (file locale, cloud, cache distribuita, database).

D'altra parte, se utilizzi la lingua con ereditarietà multipla, puoi utilizzare pattern di mixaggio , per aggiungere quel livello di persistenza all'oggetto, preservando così l'interfaccia object.store() , disaccoppiando la persistenza.

Dipende davvero dalla struttura e dalle funzioni dello storage.

Se ad esempio il tuo spazio di archiviazione è stupido e tutto ciò che devi fare è scrivere una singola istanza in un file separato, ci sono due compiti a portata di mano. Poiché non è possibile memorizzare "oggetto" su qualsiasi supporto, è necessario (1) serializzarlo e quindi (2) scrivere byte opachi sul file.

Il primo compito è la responsabilità dell'oggetto. Il secondo compito è la responsabilità dello storage. Quindi nei tuoi termini è qualcosa di simile a

fileformatWriter.store(object.serialize())

o qualcosa del genere. Il caricamento dell'archivio dall'archiviazione è più complicato, poiché è necessario determinare il tipo di oggetto che stava esaminando il numero di byte, questo passerei a un metodo factory class. Qualcosa come

object = Object.parse(fileformatReader.load())

Questo implica che le serializzazioni di oggetti diversi giocano secondo le stesse regole, quindi non c'è mai un'ambiguità.

L'archiviazione è una funzione fondamentale dell'oggetto o sta memorizzando gli oggetti come una funzione fondamentale di (parte) del sistema? Se il primo, ha gli oggetti si memorizzano. Se quest'ultimo, ha il sistema di memorizzare gli oggetti.

Secondo me, dipende dalla complessità dell'intera applicazione. Nei casi in cui:

• Hai più oggetti che devono essere scritti nello stesso file
• Il tuo oggetto da scrivere è già abbastanza complesso
• Probabilmente avrai bisogno di più formati diversi per scrivere un oggetto in.

Quindi suggerisco la seconda opzione di creare un secondo oggetto.

Ma ci sono sicuramente momenti in cui la prima opzione manterrà le cose semplici nel codice. Mi piace anche che un oggetto sappia scrivere da solo. Quindi in genere inizio con questa opzione come scelta principale a meno che qualche altro fattore non mi porti alla seconda opzione (che finisce per essere una situazione comune).

Puoi creare il metodo write (OutputStream) in cui l'oggetto si memorizza su quel flusso, che non dipenderai da qualche particolare oggetto di memorizzazione dei file e allo stesso tempo quando vuoi salvare l'oggetto sul disco non hai bisogno di sapere nulla su quell'oggetto Ma dipende da come userete questo oggetto dopo e chi ripristinerà l'oggetto.

Sono d'accordo con il Principio di Responsabilità Unica su questo: un oggetto non dovrebbe preoccuparsi delle azioni al di fuori della sua funzione diretta. Se stessimo progettando un modello di serializzazione da zero (in un modello OO), creerei un Serializer e un SerializerOverride (i nomi possono variare).

class Serializer {
   // Constructor
   public Serializer(StorageMedium sm);

   public boolean writeObject(Object o);
   public Object readObject();
   // other write/read methods if required
}

interface SerializerOverride {
   public bytes[] serialize();
   public Object deserialize();
}

Un'implementazione di writeObject potrebbe essere simile a:

public boolean writeObject(Object o) {
   if (o instanceof SerializerOverride) {
      writeToStorage(((SerializerOverride)o).serialize)
   }
   else {
      // Serialize normally
   }
}

In questo modo se l'oggetto ha bisogno di fare qualcosa da sé, può farlo. La maggior parte delle volte però non lo faranno e questo tipo di design consente inoltre all'oggetto di ignorare completamente la serializzazione e concentrarsi su ciò che è stato realmente progettato per fare.