/* * 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(); * 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 * */