====== Application overview ======
<note warning>
This is deprecated, now using Inversion of Control.
</note>
{{ :documentation:appoverview.png?direct|}}

The terms used below do not correspond to modules/classes or any concepts defined later on in this document. 
Modules can contain combinations of classes from different layers of the application.

The point of these layers is that NO LAYER CAN ACCESS CLASSES FROM A HIGHER LAYER.
This ensures code flexibility, and with other terms, loose coupling.

Application logic is currently the logic that considers the entire app as a whole, 
so changes to the application logic for one part of the software could in fact affect others parts of the software. 
This is a high dependence relationship which allows for easy changing, but should be kept as simple as possible or it could get messy. 

**The design below is somewhat outdated. Currently we have the AL and the func classes. The AL will probably have to be subdivided in some more lvls.**

**Classes with (AL) after there name are application logic classes, thus cannot be referenced by not AL classes**

==== Client/server/editor main ====

This holds everything together, and defines which classes are allowed to access which parts of the system. 
This ensures that everything fits together in a structured manner. 
There will be a close link between this layer and the plugins layer, since this layer chooses what the plugins can change,
other functionality moves to this layer.

==== Plugins ====
High level code that inserts functionality into lower levels of the application layers

==== Modular application logic ====
These classes link the lower layers together to form the actual game of The Wizards. 
These classes are actually the ‘client/server/editor main’ layer(, but only link a very small number of lower classes together, 
to make the design more flexible and independent.) These classes are currently called the actual Modules. 
So the TerrainEditorModule is the part that contains the logic of which functionalities should be used at which specific time, 
considering how the actual editor should flow (application logic). These module classes offer options to set which functionalities should be active.

==== Services ====
This layer is not really strictly defined yet. 
Its current purpose is to provide a layer that combines numerous lower classes together, 
but in a non application driver way (Not specific to The Wizards), unlike the Modular application logic layer, which actually forms the game itself.)

==== Functionality classes ====
These provide all features in the wizards, but do consider the flow of the game The Wizards itself,
or any other aspect of the flow of the application. These classes can by this design only reference other functionality classes. 
The point of this design is to have lots of different features available and let the higher layers pick the classes it’s going to use. 
There can be multiple implementations of the same functionality, simply by using other classes in its operation or small modifications. 
Not all classes have to be used in the final game. This design allows higher layers to switch from functionality to functionality at will, 
finding the perfect design amongst hundreds of possible implementations more easily.