---

examp20.cpp

This example is to show use of the Subject/Observer patterns. We basically rework ex19 so that the colleagues

• ListColleague - Maintains a list of sentences that the user can edit
• SelectColleague - Sets up the select of the sentence to edit
• EditColleague - Provides editing for a sentence

Now become subject AND observers themselves

• List - Maintains a list of sentences that the user can edit
• Select - Sets up the select of the sentence to edit
• Edit - Provides editing for a sentence

and we ditch the Mediator. The above must be both Subject and Observer because they generate and listen for events.

When something occurs in a Subject, it captures the state in a Memento which is made part of the Event. The Subject then calls the interested Observers event interface.

The flow of traffic is:

A) Lister updates the list and calls observers with a memento that contains the current list --> B

B) Select is interested in list changes, so it receives an event with the current list.

C) The main part of the application invokes Select to do it's thing, which is to display the list and allow for a selection. When a valid selection is received, it calls the mediator with a memento containing the text of the selection ---> D

D) The Edit receives the event and displays the selected string with a edit prompt. It calls its observers with a memento that contains the original string, and the replacement string ---> E

E) The List receives the event and updates it list and A then C.

It behooves me to point out that the advantage of the Mediator implementation lies in the fact that the Colleagues have NO knowledge of other colleagues, whereas the Subjects MUST know their observers. This may be limiting in some solution spaces. The choice, of course, is YOURS!!! Ain't life grand?

Some improvements to this code would be makeing the Events prototypes for submitting to observer interest.

---

This is the CoreLinux++ reference manual
Provided by The CoreLinux Consortium