What do I Mean By Context?
In a program, regardless of what language, and regardless of how simple, there is at least one context. This term works almost completely interchangeably with the term scope, but when I say context I’m adding a more vague human element to it.
Let’s look at an example:
Let’s say that a system has a single button, a device that monitors that button, and a light that is controlled by the same device that is monitoring the button.
There are a minimum of 3 contexts that exist in this system, and it could be more depending on what things have to be accounted for in the control device.
List of the Contexts:
The button is a part of the UI context (Or more generically, Input context). Adding three more buttons does not necessarily grow the number of contexts, as they can be grouped together under the already existing UI context.
The second context is the ‘System State’. This is a way to logically maintain a picture of what items are on, and off, and what users are inputting into the system. The control device will maintain this, and the diagram is being used to represent this context.
Hardware Interface is the 3rd context. This is the context where the data from system state is mapped onto the physical hardware, controlling what is perceivable in the physical world.
All systems do not always have these same 3 contexts. These are just the ones I’ve identified in this system and could be named differently so long as they represent these same 3 non-removable layers of complexity.
Why bother with this?
Having a better understanding of what contexts exist gives the developer more authority over design. Knowing how much data, and how frequently data needs to travel across contexts allows for much better decision-making unilaterally during the design process. In my opinion, context traversal causes some of the hardest problems to solve, even though it’s a tool that is meant to manage complexity and simplify code management.
