Accede agli oggetti di un contenitore con un motivo

3

Ho due classi C ++ con una relazione: una classe contenitore che ha una lista di elementi. Ad esempio, una biblioteca ha molti libri. Le classi sono la biblioteca e il libro.

Ora dal mondo esterno devo creare, aggiornare ed eliminare libri. Inoltre ci sono altre classi che sono interessate a sapere quando accade un evento su un libro e queste istanze (osservatori) possono essere create in fase di esecuzione.

Ora ho diversi modi per procedere:

1) Usa sempre il contenitore per fare l'operazione: punto centrale di gestione ma devo creare coppie di metodi per esempio setTitle (bookID) che chiama setTitle () sul libro, male;

2) Utilizzare un getBook () sul contenitore per restituire un riferimento del libro, consentire la modifica, a questo punto devo usare un metodo di commit per notificare il contenitore che può notificare l'osservatore ma in questo modo il pattern non impone un "commit", voglio dire se il chiamante esterno non chiama commit () mi libero:)

3) Usa un getBook () sul contenitore per restituire una copia del libro e un metodo di aggiornamento del contenitore per sovrascrivere il libro, il punto centrale di gestione di nuovo ma il libro se grande è un problema, un sacco di copie sono veramente cattivi.

Qualche consiglio? C'è qualche schema che copre questo caso d'uso?

    
posta user2944616 13.05.2014 - 18:13
fonte

1 risposta

1

Domanda interessante. Se la lingua fosse C # o Java, potresti usare reflection, proxy o delegati per sapere se un evento si è verificato o meno nella classe del libro. Certo, queste soluzioni sono un po 'pesanti per una questione così semplice, tuttavia il problema rimane.

C ++ non ha riflessione, proxy o delegati. Tuttavia, ciò che puoi fare è assicurarti che oggetti come Book derivino da una classe comune che tiene traccia delle modifiche.

In particolare, sto parlando del modello soggetto / osservatore. Book deriverebbe dalla classe Subject i cui unici metodi sarebbero:

public:
   bool isChanged() const;
   void resetChanged();

   void addChangeObserver(Observer &observer);
protected:
   void setChanged();

L'idea è che Subject possa dirti se un oggetto è cambiato e il suo stato modificato può essere ripristinato. Inoltre ti consente di tenere traccia degli osservatori attraverso addChangeObserver .

Book deriverebbe da Subject e Library reimposta inizialmente lo stato di modifica di tutti i libri aggiunti. Avrebbe quindi un metodo getBook e presupponendo che Book stabilisca in modo responsabile lo stato delle modifiche, in seguito% co_de potrebbe conoscerlo. Se desideri eseguire un'azione su un evento change, allora si aggiungerebbe come Library per tutti i libri aggiunti (a quel punto Observer dovrebbe anche derivare da Library ) .

Ancora una volta, questo è un po 'esagerato, ma ottieni tutti i vantaggi del disaccoppiamento al minimo costoso complicando il codice. Tuttavia, in un progetto di grandi dimensioni, è quasi necessario farlo in questo modo, dal momento che mantenere il codice disaccoppiato è sempre più importante man mano che cresce.

Spero che questo aiuti.

    
risposta data 13.05.2014 - 18:44
fonte

Leggi altre domande sui tag