If a something-or-other is polymorphic, it can take more than one form. Polymorphs have a certain popularity in fiction, from witches capable of looking old or young to robotic hunter-killers made of liquid metal. Being polymorphic is usually portrayed as a very handy sort of ability to have, as characters with such a trait can literally mold themselves to fit a variety of situations.
- In object-oriented programming, polymorphism manifests itself in the ability of different data representations to appropriately leverage some common framework. These common frameworks can also be called “interfaces.” If I create a data type that uses a common framework, I can also say that the representation I've created “implements the interface.”
- For example, let's say that I create an interface called “Fade-able.” This interface is meant to provide a common framework for the inner workings of graphical volume controls. Now, let's say that I end up creating two types of graphical volume control. One is a virtual, linear potentiometer. A slider – or, a “fader” as we would say in reference to what we see commonly on mixing consoles. The other graphical control that I come up with is an angular potentiometer, or a knob. As I create their respective operations, I require that both “Fader” and “Knob” implement the “Fade-able” interface. “Fade-able” might require a number of things. It might specify that a control has to be able to report its position in a certain numerical way. It might also specify that a control sensing a mouse or touch cursor in a bounding box will move the cursor to the control's set point, rather than having the control jump to where the cursor is. These requirements are “enforced” by the way that the “Fade-able” interface is written, and when it comes time to write the implementations for “Fader” and “Knob,” they must be coded to comply. They certainly aren't coded the same way. “Fader” reports its position based on a line, whereas “Knob” uses a circle. “Fader” might allow for +20 dB, whereas “Knob” might be limited to +10 dB. Even with those differences, however, they are recognizable as obeying the rules of “Fade-able.” It's just that their ”fade-ability” takes the form necessary to operate properly and predictably in each context.
- Now, unless you're doing programming “from scratch,” this is a pretty abstract idea. Is there any way that this can apply outside of computer code? If you're thinking that the answer is “yes,” then you have successfully predicted my response.
- One way you can use this concept of polymorphism is with projects. You can use it as a way to codify how any given project obeys a basic framework that you want to see. In some ways, you might already be doing this naturally. For instance, you might have a “total quality system” that you apply to everything that you or your shop does. Any project or activity has to implement the “total quality system,” or it's not being done correctly. Precisely how that comes about is different for installing a projection system versus providing a one-off loudspeaker and wireless microphone rental. It's polymorphic, because it looks different in each specific case. However, that polymorphism does not make the total quality system unrecognizable. Rather, it means that the total quality system has a carefully thought out set of basic requirements that remain recognizable in any form.
- “Now, wait a minute,” I can hear you say. “If I'm already doing this naturally, then why talk about it?” The reason to talk about this as a concept, rather than just a “happening,” is that the concept can be designed, measured, refined, documented, and carefully predicted. By no means does any of that require oppression, rigidity, closed-mindedness, or an inability to allow for a natural flow. All that means is that a point is being made to think things through and make them better. For instance, if you've naturally arrived at a set of basic quality standards for a project, that's fantastic! There's no need to throw anything out. Instead, you can ask yourself, “How did we arrive at these standards? How can we thoughtfully encourage arriving at similar standards in the future? How do we generalize these standards so that we can have an objective idea of them being present in any project?” You're taking something that “just happened” in a very good way, and are trying to figure out how to make that very good something happen when you want it to.
- In doing this, you are creating a set of rules, but the downfall only comes if the rules are seen as infallible. You can avoid a lot of pain and suffering if you're willing to say that the framework might not have actually been gotten right on the first try. It's entirely possible for a framework to have a specific directive that isn't polymorphic; it can't actually be generalized. For instance, a quality standard might mistakenly require that any installed console have 100mm linear potentiometers. Speaking broadly, this would seem to make sense. However, what if there's that one job where a console with 60mm faders would be a good fit? Is using the console with short-throw faders a violation of the quality standard, or is the quality standard not actually polymorphic enough?
- In closing, I want to make sure that I mention that this long discussion of a quality standard is just one example among many. You can use frameworks and polymorphism in a lot of different places, from how you order rackmount components to how you keep your books. The point is that you can create a way for things to fit together that flows (and flows naturally) from generalized principles to specific ones, and have a very clear idea of how that flow works. It's not that these kinds of things aren't thought about in some way – this is just a different method for thinking about them.
