Encapsulating functionality behind a well-defined interface


Most traditional programming languages provide several ways to abstract away complexities of code, and instead present a well defined interface.

What does that mean? Well, in simple terms it’s a restricted set of entry points into that code that make it clear how you can interact with it.

Was this email forwarded to you?


Take, for example, a web page with a form that takes your username and password. The interface is made up of the username field, the password field, a ‘forgot my password’ link and perhaps a few other links. Other than that, you don’t really have any other access to what’s going on behind the scenes.

You can do the same over a piece of code - for example in many languages you would define a module or class that processes someone’s login information. You might expose a function for setting the username and password, something like:

login.request(username, password)

and perhaps a way to ask whether login was successful, and perhaps a ‘key’ to access the user’s information in other parts of the code once they have been confirmed.

Apart from these exposed functions, the rest of the encapsulated code is usually hidden away from the other parts of the program. Typically the developer’s tools will help out by listing the functions that are exposed as you write the program. Something like this:

You can also define your own restricted interfaces around parts of spreadsheets as well - though it takes a little bit of knowledge of how a few features work together.

Later on we’re going to go through three examples based on the scenarios we talked about earlier:

  1. Blocking out and even restricting navigation to data input areas.
  2. Encapsulating a lookup table for reference data.
  3. Encapsulating calculations, and using named ranges as the interface.

Until next time, thanks for reading!

– Brendan

p.s. Enjoy this message? Read more at the Hyland Quality Systems website.

The Daily HaiQu

I'm Brendan Hyland. I help regulated facilities transform their software, spreadsheets, workflows and documents from time-consuming, deviation-invoking, regulatory burdens, to the competitive advantage they were meant to be. Join me every week as we take a few minutes to explore, design, test and improve the critical systems we use in our facilities.

Read more from The Daily HaiQu

Last time we left off with a cliff-hanger of a question: How do you prove you're you when signing a document? There are several ways I've seen that the 3rd party providers prove that it's you who's signed the document: You clicked a link from an email. You paid for the service with a credit card. You provided some government issued photo ID. Someone, such as a notorized public or your HR department, has verified it's you in person. Obviously these are very different levels of assurance. Then...

There are several levels of 'signatures' that you can apply to an electronic document. The first and most basic is just an image of your written signature. One common option for this is to print the document, sign and scan it back in again. A more convenient version is to have an image of your signature saved that you can paste into documents. This is what many free versions of pdf software and word processors offer as a basic document signing option - a 'stamp' of your saved signature image....

Ever since COVID, document and signing workflows have been incorporated into everything. Dropbox has it. Microsoft Teams has it. Google Workspaces has it. If you need e-signatures, you probably have access to Docusign, Adobe, Hellosign, and so on. But what exactly are we talking about when we say "document and signing workflow"? Let's step back. Most document workflows are about moving some work through review, commentary, revision and approval. The old way to do this was to send a document...