Talk about the NiCE data structure Philosophy, why we do things, the patterns, etc.
The NiCE development team wanted a data structure that was not only flexible but versatile in many situations. Many developers today spend countless hours writing and rewriting their data structure backbone by adding pieces with limited or inflexible usage. The NiCE development team decided that in order for the product to be successful, the backbone data structure design needed to be useful in multiple types of situations with little to no rework of the structure. Tools like xml manipulation, database consistency, and in memory data storage should be features apart of the design and not separate components. Also, moving away from constant intermediary data marshaling to limited data structures was a critical success with the current ever evolving data structure architecture within NiCE. This limited many lines of code and maintenance where data structures are adapted to requirements instead of dropped. This kind of thought helps us eliminate legacy code and decrease the learning curve dramatically for new developers to the application.
The data structure follows a very fluid, yet rigid, set of designing pattern principles that provide the programmer with extensive power in a small package. If the programmer wanted to add a data structure to a MVC (Model Viewer Controller) structure, then the observer pattern exists within the relationship between the form and component. If the developer needs to add more types of data structures to the GUI, like a list of imported images, then the composite pattern on the form provides the tools to implement a new sub-data structure architecture. These, and many others, were thought, modeled, implemented, and tested into NiCE in order to provide more usability and agility in a constantly requirement changing programming environment.