- If you rewind a couple of years, I was finally finishing my long-delayed Bachelor's degree. After a very long run of insisting that I was "never, ever, going back to school, and that's final," I had finally found a school and program that fit the way I think. My program was Information Technology, and near the end of it I was properly introduced to object-oriented programming.
- It was a surprisingly lovely experience, especially compared to an introductory college course in programming that had occurred in the distant past. That introductory course, given at a traditional institution, was horrifically bad. Almost nothing in the way of real, ground-level concepts were presented. Instead, it was all about making a particular programming language not bite you in the bottom. In many ways, this battle was fought by rote knowledge. By contrast, the second time around in this area was marked by being taught WHY things worked, and this made a tremendous difference in the approachability of the subject. Of course, it also helped that the language and development environment used were pretty forgiving.
- But I digress. This isn't an article about what works and what doesn't when doing training. Nevertheless, Simba, we are all connected in The Great Circle of Life. (That's a reference to "The Lion King," if you didn't know or don't remember.)
- Anyway, because I was being taught concepts, it became much easier to see how the world of writing code intersected with the world of physical reality. In a number of ways, the concepts used for writing object-oriented programs are applicable to practical issues of companies, people, and projects. One of these practical issues is encapsulation.
- For a programmer, encapsulation means that the internal structure of an object is hidden from processes working on that object from an external reference frame. This is not necessarily meant to entail secrecy by obfuscation; an object need not be a black box, and one need not be paranoid about someone figuring out how something is structured. Instead, encapsulation empowers external users to leverage an object without having to know everything about that object's internal representation. Further, it allows for the access to that object to be carefully defined and controlled, thus helping to ensure that the program maintains a consistent and predictable internal state. (These ways of accessing and changing an object are called "methods”.)
- If you have a finite number of ways that an object can be manipulated, and those ways are carefully crafted, then you have a theoretically finite number of logically understandable states that the object can enter. It's easier to prevent an object from entering an invalid state, and it becomes easier to know if an object has somehow gotten into an invalid state. By contrast, allowing unrestricted and direct access to an object means that the object can be externally forced into all manner of unexpected states, and it may not be at all obvious how it got there.
- This probably seems like a really abstract sort of idea, so let me present an example. It's going to start out with a "very extremely bad idea."
- Let's say that I've created a system for setting a gain control in a digital audio system. An end-user interacts with that gain control via a wall panel that shows a text box and virtual numeric keypad. I do nothing to encapsulate that "gain object”. The representation of gain in the system is nothing more than a number with a decimal point. The user is expected to put some number into that text box.
- Intuitively, you can see that this is aggressively user-unfriendly. Why? By not using any encapsulation, I have firstly required that the end user know exactly how the "gain object's" internal structure works. Is it a multiplier, where entering "0" sets all sample values to digital silence? Is it a representation via decibels, where entering "0" passes all the sample values along unchanged? Is it an arbitrary mapping where "0" could correspond to pretty much anything? If you don't know, you can't use the control effectively.
- Further, because I haven't done anything to encapsulate the control, I have no way to restrict what an end user can do to that control. I can't prevent you from entering some value that's completely out of the object's valid range. I can, of course, continuously check that the object is in some valid range, but I have to do that from some point that's effectively external to the object. Even so, a valid range might still be...aesthetically displeasing. If I'm not careful, the user could suddenly have a very loud experience, or a very silent one, and have no way of knowing how to fix the problem.
- Now, what if I create a fader control? What if I limit the fader travel so that the user can't go over a certain volume? Aside from creating a familiar control metaphor, I've also engaged in encapsulation. I'm not hiding the workings of the gain control for the purposes of secrecy. Instead, I'm hiding them so that the user can make something happen without being forced to know exactly how it all comes about. Further, I'm able to limit the user's inputs to things I can predict and "fence in" to a valid range. If, for some reason, the gain control was ever able to enter an invalid range, I would know that there was a problem in my creation of the system and not the user's input. (If the user can introduce an invalid input, then I must have made a mistake in my creation of the control.)
- Is this applicable to AV? Of course it is—in fact, one way to do so has just been demonstrated above. It is 100-percent worth it to take the time to craft end-user system interactions that allow for predictable, controllable, and repeatable results by people unfamiliar with the inner-workings of a system. (Being able to adapt that encapsulation dynamically to different levels of familiarity and competency is a challenging bit of work that you can do for "extra credit”.) The big thing, though, is that having the core concept of encapsulation in your mind lets you measure the effectiveness of a control scheme in an objective or semi-objective way. Beyond just an impression of "is this easy to use," you can actually create metrics to evaluate whether a control scheme removes the need for understanding inner workings, while also allowing for control and prediction over end-user control inputs.
- Also, please note that I am using generalized language. This can apply to any kind of control scheme, not just those that present a virtual interface. An analog mixing console encapsulates the console operations inside a chassis, and presents methods like faders, knobs, and switches to the user. These controls, when working properly, allow the user to operate the device without knowing how it was constructed. They also impose limits on how the user can control the device, thus making that control well defined, predictable, and repeatable.
- What may be even more surprising is how this can expand to organizations. A small company might very well have interactions between, say, the pro-audio and video presentation departments—and those departments may not be encapsulated at all. Maybe everybody knows the inner workings of each department. There's nothing wrong with that. In fact, it's commendable. However, what if that organization grows to the point that it's not practicable for everyone to know exactly how every other department works? At that point, the organization can benefit enormously from good encapsulation. It's not that the inner-operations of the pro-audio department are meant to be secret from the video presentation folks, or from the people in marketing and sales. Not at all! However, good encapsulation ensures that people who don't know how a department works can interact effectively with that department.
- If there are well defined methods for, say, requesting proposals, subdividing tasks within inter-departmental projects, handling project changes, general communication, budgetary management, and so on, then all of those things can be done efficiently and predictably. Some of this happens naturally through the process of creating a chain of command, but it can get much more refined if you can have some measure of the degree of encapsulation in play, and whether or not that encapsulation is elegant. (Encapsulation isn't necessarily something that is automatically good. It can be done badly if not done with care.)
- I will crawl out on a limb, and say that truly effective delegation is not possible without good encapsulation.
- To close, I want to address the possible concern that encapsulation stifles creativity and flexibility. It certainly can, if done badly. However, I do not believe that encapsulation necessarily requires an inflexible system. If someone dreams up a new way of getting things done, and that way requires a change to a system of encapsulation, then change the system! If someone is getting unfairly stonewalled or steamrolled because of an encapsulation system, then change the system!
- Encapsulation does not cause institutional rigor mortis. Rather, organizational rigidity causes encapsulation to become nothing more than an obstacle course. The point of encapsulation is to have meaningful rules that empower people to get things done. If those rules stop empowering people, then it's time to rework those rules until people get their leverage back.
- Danny Maland has experience in both the recording studio and live-sound reinforcement worlds. In the last few years, he was a key player in establishing and operating "New Song Underground," an all-ages music venue offered as an outreach by New Song Presbyterian to Salt Lake City, UT. He is currently a "freelance inconveniencer of electrons and air molecules." Maland holds a vocational diploma (MRP II) from the Conservatory of Recording Arts and Sciences, and also a Bachelor of Science: Information Technology from Western Governors University.
