Encapsulation

Although encapsulation is considered one of the four cornerstones of OOP it is not limited to this, and can be implemented in Dynamics NAV as well. When implementing encapsulation, we hide the components from being wrongly used.

In other words, we indicate to other developers which functions can, or cannot be used outside the class, or as in Microsoft Dynamics NAV, the object.

This is achieved by implementing the local functions. Microsoft Dynamics NAV allows functions to be global or local. Global functions are allowed to be called from outside the object; local functions can only be used inside an object. In C#, these would be public and private functions.

When we want a function to be local, traditionally in C/AL we have to explicitly set the property. However, this has changed in Microsoft Dynamics NAV 2015. In this version, all the functions are explicitly set to local, and as developers, we have to change the property to No if we want the function to be available outside the scope of the object.

Encapsulation

Before this change was implemented, the consideration of making a function global or local was often ignored by developers. When accidentally calling to a function that was designed only to be used internally inside an object, unexpected things might occur, especially when the original developer changed the behavior of the function, assuming that it was never used outside the scope of his object.

Encapsulation can be related to the class-method-property model, interfaces, and Natural Language Programming.

If we treat a table like a class and make functions a method of the class, these functions should be global. Therefore, the default value of the Local property of a function has a negative impact on this model. If we implement this methodology, we have to change the property to No always, so the function is global and callable as a method of the table.

Tip

Whenever a function in a table could be local, it indicates that we should switch to a Codeunit, implementing Natural Language Programming.

Functions in a table should almost always be callable as a member of the table, and be related to the table as an owner of the process.

Note

This video explains how to implement encapsulation in C/AL. You can watch it at https://www.youtube.com/watch?v=xsi2BjUY4IU.

Interfaces and Function Libraries can have more than one global function. Function Libraries are often collections of the related features. These Codeunits can have local functions that perform logic, which is shared across the functions. Interfaces typically have one global function, which represents "the interface". However, there could be more global functions that allow small variations of the interface, requiring other parameters, comparable to overloading in other programming languages.

Encapsulation really becomes powerful when designing functions using Natural Language Programming. With this combination, we can separate the internal code from the owner. An example of an encapsulated function in Microsoft Dynamics NAV is Codeunit 99000854, Inventory Profile Offsetting, as displayed in the next screenshot:

Encapsulation

This Codeunit handles a complex algorithm for Inventory Calculation, and uses a variety of Patterns and methodologies, which makes it interesting material to study.

Override Functions

When Encapsulation is implemented, many programming languages allow developers to override local functions and replace their code. This is not possible in C/AL. Once an encapsulated module is called, there are no exit points for customizations. When we expect that our software is likely to be extended or even replaced by some other code, we can implement a Façade or Hook.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset