/*
 * 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-where Who observes what?
 *
 * Where to look for a specific update is very important. Hence, we list here
 * all (major) Observables and what exactly they report in their channels:
 *  -# \ref World: Gives updates on insertion or removal of atoms and molecules.
 *     It does not tell whether the inner state of either has changed.
 *  -# \ref atom: Gives updates on changes to inner state of an atom, i.e.
 *    -# bonds
 *    -# element
 *    -# position
 *    It does not tell when e.g. it is associated to another molecule and
 *    like-wise not if its AtomInfo::Nr changes, as this is given by the
 *    molecule also.
 *  -# \ref AtomObserver: Gives updates on changes occuring in any atom. It
 *     acts as a relay that observes all atoms at once and gives notice when
 *     a single one has changed. It does not tell when a new has arrived or
 *     one has been removed.
 *  -# \ref molecule: Gives updates on changes occuring in its internal state,
 *     e.g. atoms being inserted or removed. It does not tell when atoms themself
 *     change.
 *  -# \ref Box: Gives updates on changes of its box matrix or boundary
 *     conditions.
 *
 * It should be adhered to these Does and Don'ts strictly. Each of these entities
 * can only report about stuff it knows about. The World controls insertion and
 * removal, hence its updates are concerned with these only!
 *
 *
 * \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
 *
 */