Interfaces: A Balance Between Control and Safety
We’ve been having a fun internal conversation (to people like me, anyway) over the past week about interface objects and the benefits of interfaces. I’ve been programming for going on 25 years now and have used interfaces in all manner of programming languages since I started, but I have to remind myself that many developers don’t have that same exposure, especially in the Microsoft Dynamics 365 Business Central world. To them, this is an entirely foreign concept that they are only now starting to see in practice.
The battle I’ve been fighting revolves around a central idea that the interface and its implementation are two completely different things. Even though we’re having one, there is no debate on this concept–no alternate facts. An interface is simply a contract. That contract states what is expected of you as a developer if you want to interact with a certain part of the system – what your code has to be able to do. Most importantly, it does not tell you how you have to implement it. Interface objects can’t have code in them, they can’t be executed, and they can’t be debugged. By definition, they can’t do anything on their own.
Specifically, we’ve been talking about the way Microsoft has designed and implemented the Data Retention module. We should remember we’re talking about a feature that is used by end users, not developers. This feature is not trying to tell developers how they can delete data from the database; it is telling users how they can safely manage the size of their database in the face of capacity restrictions. Let’s look at why using interfaces was a better design choice with a simple question that we should all know the answer to: “Should a user be able to delete any data they want to?”
Obviously, the answer is no. It is such a loud and resounding no that it needs to be enforced no matter what. And thus, an interface, a contract must be put in place. The contract for the module says, “If you want to work with me, you’d better have a way to decide which tables can be added,” but it certainly does not tell you how to make that decision.
So, who does make that decision – the implementation part? The implementer, of course. In this case, Business Central comes prebuilt with an implementation, so more often than not you’ll be relying on how Microsoft chose to implement it, but if you were building your own data retention module on top of the existing interface, you would make that decision. Microsoft’s implementation says the creator of the app gets to decide; they have to opt in to allow their tables to be used. This is why you can’t just go and select the G/L Entry table in the Retention Policy Setup List – you didn’t create the G/L Entry table. It’s also why you can’t add a table from an app you found on AppSource. This makes the most sense as the creators likely know the most about the structure of their app and provide the biggest safety net. That is one of the benefits of interfaces.
Interfaces are your friend. They were not added to AL to force you to develop in a certain way. Just like automated testing, there are benefits of interfaces: They are there to help you help yourself and to prevent bad things from happening. We don’t live in a world where every developer goes through proper AL development training, or in a world where there is even a developer license anymore. Anyone can be a Business Central developer, and that’s a good thing. But it does require a little more hard-coded enforcement in certain situations.
Have a question about development? Contact me any time.