The basis of the Module feature is explained here: encapsulation. In other words, the purpose of Moduless is to make the process of designing applications easier by making it possible to organize a Knowledge Base into different sections — Module objects — focused on providing a reduced series of highly specialized services. All such sections cooperate towards achieving a more complex service. This enables developers to focus on developing functionalities without the need to know about the rest of the application, nor its interactions. So, the Module object enables designers to break down a problem into two or more sub-problems of the same (or related) type. These sub-problems are simple enough to allow for a direct solution, which is then combined with the solutions to other sub-problems using the Interfaces defined to find the solution to the original problem.
During the development stage, GeneXus objects are most likely to change, making the design and definition of the right interface something essential to protect other Moduless from those changes. It is highly recommended that following the definition of the group of objects belonging to the interface, changes made in them be kept at a minimum. This ensures that maintenance and development will be as simple and fast as possible.
A Module’s interface may be defined using the Object Visibility property — read Modules - Defining an interface for further information. Then, the interface may be examined using the Module Interface Tab.
As development continues and services become available, the interaction between Modules begins. More often than not, it is not easy to see how Modules interact with one another. To make this task easier, we could define Diagrams showing the relationships between Modules — read Module Diagram Tab.
By knowing these interactions, designers can fine-tune interfaces and create a more efficient and understandable solution, in addition to making an early diagnosis regarding the possible misuse of services.
The Module feature will not change the way in which objects are called or used when defined in the Root module, nor the generated code when no module is defined. However, when objects belong to a Module, we must consider the following: