Not a big reader? Watch the video of this blog here on YouTube!

Encapsulation is one of the four corner stones of object oriented programming and it is about componentizing your software, it’s basics go back even to the 1970ies. In this article we will investigate how we can introduce this concept in Dynamics NAV.

Elements of encapsulation

Encapsulation is about creating small reusable components grouping features that belong together.

A very important rule here is to be as local as possible. The intention of being local is to prevent the wrongly use of features.

Within Encapsulation a programming language typically allows override, just in case it is required and the programmers know what they are doing and why.

Encapsulation is tightly related to the Object-Method-Property model that we discussed in the first video of this series of implementation patterns.

Keywords

If we take some keywords from this list, we need to define Small, Usable, Local, Hide and Override.

Microsoft Dynamics NAV.

A small reusable element can be a Codeunit. Within the Codeunit we can have functions that can be global and local. Global functions can be accessed always when we declare the Codeunit as a variable. Local functions can only be accessed from the object itself, thus the Codeunit. This allows us to be as local as possible and implement encapsulation.

In Microsoft Dynamics NAV2015 functions are local by default. This is to encourage encapsulation.

Let’s take an example. We could create a Codeunit for VAT and SalesTax calculation. This Codeunit has one global function that is called CalculateVATAndTAX which takes an argument table as a parameter. The business logic will be in local functions that are only accessible from within the Codeunit.

With this example we have creates a small but usable component of features that belong together and business logic that is as local as possible. Hence we have implemented encapsulation in Microsoft Dynamics NAV.

In the Application

Unfortunately I have to admit that encapsulation is not implemented throughout the product. There are reasons for that which I will explain in another episode of the series. But it exist. A very good example is Inventory Profile Offsetting. This Codeunit has a global function that takes an Item, some setup and other parameters and then start a logical order of functions. These functions are local.

The goal of using local functions is to avoid the wrongly use of them. This way the designer makes a clear intention of which functions you can call, and which functions should never be called from outside the object. This is one of the fundamental basics of encapsulation.

Mapped to C#

If we take this learning and go back to the first pattern of this series, Class, Method, Property we can now expand this with Public and Private, these are the keywords for Global and Local functions in C#.

Natural Language Programming

We can also relate this to the second pattern, natural language programming where we separate readable code from nerdy code. The readable code are the local functions and the nerdy code is the C/AL code in these functions.

We are starting to get a completer picture here, and this is why I’ve put these articles in this specific order.

Override

Now we discussed Small, Usable, Local and Hide. We have not discussed Override. There is a good reason for that.

Most programming languages have built in mechanisms for overriding. C++ uses friend and C# and other languages have reflection.

C/AL does not have anything built in that allows this. If we want to override, we have to hack into the source code and change the behavior. This is the reason NAV is open source.

However there is another implementation pattern that allows override, which is the façade pattern. This pattern is based on decoupling and should be implemented if there is a clear expectation of overriding being required. In Dynamics NAV it requires extra coding, objects and it makes the of the business logic intention less clear.

Global & Local

So does this mean that with encapsulation each Codeunit should have one global and multiple local functions? No. There are a number of patterns that require more than one global function in a Codeunit such as implementing API’s, management codeunits such as journal management and the Model View-View Model pattern. This often relates back to reusing global variables in memory state or keeping software features together in one class, which relates back to one of the fundamental basics of encapsulation.

Be as Local as possible

We can however create one clear statement: “Be as Local as Possible.”. Which is enforced by Dynamics NAV 2015.

So when we look at the key elements of encapsulation we can say that one of the corner stones of object oriented programming can be implemented in Microsoft Dynamics NAV and helps us to clearly structure our code and emphasizing the clear intention of the designer.