Before we start coding, we need to find the owner of a process. If we explicitly connect the process to the owner, it will be easier for everyone who works with the object to understand what it can do.

Let's try to clarify this with an example. One of the processes that has a lot of owners in Microsoft Dynamics NAV is printing an address. We can print addresses for customers, vendors, documents, and more. In Chapter 2, Design Patterns, we have learned the Pattern to use and print addresses.

If we want to print a customer address on a report, we have to perform the following steps:

The following screenshot shows the Report Designer window:

This will return a populated address array that we can use on a report.

But how do we know that the Codeunit FormatAddress exists, and has a function that can be called with a Customer record?

The answer is experience, training, and reverse engineering.

Wouldn't it be nice if we could look at the Customer table, and see what we can do with it?

To do this, we need to implement a new function on the Customer table. Let's call it FormatAddress. We'll give it the Addr text variable as a parameter. Codeunit 365 can be a local variable in the function, as in the next screenshot:

When we do this, we can use the FormatAddress function each time we have access to a customer record without declaring a Codeunit, or even knowing that it exists. If we apply logical naming, and group similar functions together, other developers will find it easier to know about these functions. The suggested naming should always contain a verb and noun.

Now that this function exists, we can simply refer to it from our report without declaring the Codeunit. We only need the Text array.

This way of working with functions as a member of the process owner is normal in object-oriented programming, where we will use classes. Using this methodology, we treat an object in Dynamics NAV as a class. We preferably add business logic to a table, and create a Codeunit if the code becomes complex, which typically is when we need more than 10 lines of code.

Another example where implementing this methodology makes sense is working with Documents. Most documents have multiple processes such as release, reopen, post, copy, and more. Most of these processes are in Codeunits in the system. By creating these processes as a function in the table, it would be easy for developers to call them from the user interface.