I’ve two C++ classes with a relation: a container class which has a list of items. For example a library has got many books. The classes are the library and the book.
Now from the external world I have to create, update and delete books. In addition there other classes that are interested to know when an event on a book happens and these (observers) instances can be created at run-time.
Now I’ve got different ways to proceed:
1) Use always the container to do the operation: central point of management but I have to create couples of methods for example setTitle(bookID) that call setTitle() on the book, bad;
2) Use a getBook() on the container to return a reference of the book, allow the modification, at this point I have to use a commit method to notify the container which can notify the observer but in this way the pattern doesn’t force a “commit”, I mean if the external caller doesn’t call commit() I loose 🙂
3) Use a getBook() on the container to return a copy of the book and an update method of the container to overwrite the book, central point of management again but the book if big is a problem, a lot of copies are really bad.
Any tips? Is there any pattern that covers this use case?
2
Interesting question. If the language were C# or Java, you could use reflection, proxies, or delegates in order to learn whether or not an event occurred in the book class. Granted, these solutions are a little heavy handed for such a simple matter, however the problem remains.
C++ doesn’t have reflection, proxies, or delegates. However, what you can do is ensure that objects like Book derive from a common class that keeps track of changes.
Specifically, I’m talking about the Subject/Observer pattern. Book would derive from the Subject class whose sole methods would be:
public:
bool isChanged() const;
void resetChanged();
void addChangeObserver(Observer &observer);
protected:
void setChanged();
The idea is that Subject can tell you if an object has changed and its changed status can be reset. In addition it lets you keep track of observers through addChangeObserver.
Book would derive from Subject, and Library would initially reset the change status of all added books. It would then have a getBook method and assuming Book responsibly sets the change status, Library could later know it. If you wish to perform an action upon a change event, then it would add itself as an Observer for all books added (at which point Library would also have to derive from Observer).
Again, this is a little overboard, but you gain all the advantages of decoupling at the slight expensive of complicating the code. However, in a large project, you almost have to do it this way since keeping code decoupled is increasingly important as it grows.
I hope that helps.
3