source: src/documentation/constructs/observers_observables.dox@ 936a02

/*
 * Project: MoleCuilder
 * Description: creates and alters molecular systems
 * Copyright (C)  2010 University of Bonn. All rights reserved.
 * Please see the LICENSE file or "Copyright notice" in builder.cpp for details.
 */

/**
 * \file observers_observables.dox
 *
 * Created on: Oct 12, 2011
 *    Author: heber
 */

/** \page observers Observers and Observables
 *
 * The Observer/Observerable mechanism is crucial to let different and
 * independent components know about changes among one another. E.g. when an
 * the element of an atom changes, the GUI (\ref graphical) needs to know
 * about this change to plot the atom with a different color or shape.
 *
 * The Observer/Observerable mechanism is basically just a call-back: A
 * class announces itself as Observable with having a specific interface
 * of functions. Observer may signOn() to this class and have a specific
 * function (update()) be called whenever a change occurs in the Observable
 * class.
 *
 * Note that additionally an Observable may have various \a channels and
 * Observers may signOn() to just such a channel to get a very specific
 * update. E.g. a LinkedCell class needs to know when the position of an
 * atom changes but it does not need to know about changes of element or
 * velocity, ... These updates are called \a Notifications.
 *
 * As an example:
 * \code
 * World::getInstance().signOn(this, World::getInstance().getChannel(World::AtomInserted));
 * \endcode
 * Here, in the constructor of GLWorldView the class signs on to atoms
 * being inserted into the World such that it can add these onto the display
 * as well. Notifications are received via recieveNotifications(), e.g.
 * which you have to implement for an Observer class
 * \code
 *   switch (notification->getChannelNo()) {
 *   case World::AtomInserted:
 *   {
 *     const atom *_atom = World::getInstance().lastChanged<atom>();
 *     emit atomInserted(_atom);
 *     break;
 *   }
 * \endcode
 * Here, we just switch over all events that we process and care about (note
 * that we only get called for those for which we have subscribed) and proceed.
 *
 * \note There is a complete logging mechanism available for this. However,
 * it has to be compiled via a specific switch (\ref install). So, when
 * you need to know why your function isn't notified, that's the way to
 * find out.
 *
 * Be wary of where the update occurs: while the World tells you about new
 * or destroyed atoms, only the atom itself tells you when its position has
 * changed!
 *
 * \section observers-world Observers and the World
 *
 * The World, containing the arrays of all atoms and molecules, is a bit
 * special with these observers. E.g. when you request a non-const array
 * of atoms you receive an ObservedIterator. That is one where automatically
 * it is assumed that you changed something and hence update() is called
 * after you stepped over one of its elements.
 *
 * Thus, use const-iterators and arrays whenever possible, first to avoid
 * this overhead, but second to avoid making pain-in-the-ass, hard-to-find
 * mistakes.
 *
 * Also, the world stores specific information about what changed in the
 * template function World::lastChanged() where it might contain reference
 * to an atom that is about to be destroyed or just added.
 *
 *
 * \date 2011-10-31
 *
 */