When working with objects and methods in ERP, we traditionally implement them directly. In other words, we implement tight coupling. The class calls the method, and the method only accepts calls from the object. We cannot run a Codeunit with a record that it does not relate to. This ensures a contract, the table, between the class and the method, allows the compiler to check integrity and prevents the software from being wrongly used.

In C/AL Code, this would look like: SalesPost.RUN(SalesHeader), which ensures a tight contract between the Codeunit (SalesPost) and the table (SalesHeader).

In OOP, we can also implement loose coupling. When this is implemented, we implement an intermediate class in between the object and the method. This allows flexibility, but it increases the risk of the wrong use of the software. At design time, the method does not know its caller, and the caller may not know the method.

The Façade Pattern allows us to design software with great flexibility, since a change in the method does not require a change in the source code. We can simply create a new implementation and call this instead.

This requires great discipline from the software architect and developers. When used wrongly, anti-patterns such as code cloning or boat anchors are just waiting to happen. We will discuss these in the next Chapter 6, Anti-patterns and Handling Legacy Code.

To avoid being wrongly used, in OOP, we can implement abstract classes. When doing this, we can force the method to have a specific signature.

C/AL does not allow this flexibility of calling a Codeunit with multiple records. We can only ensure the type of record variable that we send to a function. When working with Variants, which we will discuss later in this chapter, we don't even have this assurance.

When the record itself is not suitable as a contract for the function, we may consider implementing the arguments Pattern as a contract for the Façade.

Let's have a look at the Façade Pattern with an example.

As discussed earlier, we should only implement Façade when flexibility is required. This can be the case in the scenario of getting the weight from a weighing scale. There are many manufacturers of scales that have different interfaces, but from a business perspective we only require a single value—the weight.

To implement this, we need to add a member to a table called GetWeightFromScale, which returns a decimal value for the weight. This function calls in a Façade Codeunit that is able to determine the type of scale, based on setup. If we need this weight in other application areas, we have to consider creating an interface.

For the sake of simplicity, we will print the weight to a message box:

The Codeunit reads a Scale from the Setup table. Based on this setup, a specific Codeunit is called. The use of an argument table ensures the contract and that the Codeunit is not called with wrong parameters by accident.