Editor’s note: Christine Miyachi is principle software systems engineer and architect at Xerox Corporation.
This kind of thinking is fundamental to MIT’s System Design and Management (SDM) Program, and as an alumna I frequently try to draw lessons from one domain and apply them to another. I like to ask myself, what is the essence of the principle and how can it be applied more broadly?
One particularly useful software principle is polymorphism, and I have recently been intrigued by the possibilities this software principle could hold for systems engineering as a whole.
In software engineering, it is understood that software objects should have only one function; yet the principle of polymorphism allows for abstract software objects to have more than one function.
The word itself derives from a Greek root meaning "having multiple forms." In object-oriented programming, polymorphism is the ability to execute a function specific to a context. The classic textbook example is shape objects. A shape is a general object and a circle and rectangle are more specific objects that inherit from a shape. A circle is a shape and a rectangle is a shape.
In a program, the shape object can be used to draw any shape without knowing what exact shape it is at compile time. So this is useful with software—less code makes it easier to understand the abstraction.
In the non-software world, physical objects can also have more than one function; systems engineers often want to fit many functions into a single piece of hardware. For example, in my SDM class in systems engineering, we talked about a seat cushion in a boat. The cushion serves two functions—as padding for a seat in one context and as a flotation safety device in another. The design of this seat cushion has been influenced by the fact that it has two functions. However it’s basic core function is to lift a human—whether it be on a seat or in the water.
The SDM program, which exposes students to experts from a wide range of disciplines, really emphasizes the value of identifying broader concepts that can be applied across domains. Having learned how such cross-disciplinary thinking can speed up the problem-solving process, I decided to examine how polymorphism could be useful in the design of larger systems.
Take vehicle manufacturing, for example. Imagine that you could drive a vehicle in the same way on the street, in the air, and in the water. You just knew how to drive and it worked the same way no matter where you were. That’s the essence of polymorphism, and that’s useful to the customers of my product—which is a machine that has multiple functions.
Using the vehicle example again, you can see how polymorphism could save unit manufacturing cost. If you want a vehicle that drives over land and floats in water you could buy two vehicles, one that runs over land and another that moves in water. Or, engineers could design you one vehicle that does both.
The multipurpose vehicle is more expensive than a single purpose vehicle, but should be less expensive than two vehicles (one for land, one for water). That is the challenge with polymorphism. If customers really want a multifunction device, and if we can find a way to reuse systems to perform multiple functions in a cost-effective manner, then polymorphism works for our business.
Polymorphism also has a role in product platform design. For example, a platform has a set of common functions. How that functionality is implemented will vary depending upon what system the platform is on. Consider an example from my product design and development class: a power tool served by a power supply that could fit onto a variety of tools and be switched between them. Like the shape and the draw function, the basic functionality of obtaining power remains while the function of doing the work varies from tool to tool.
Of course, polymorphism isn’t always the best idea. In product design, there are tradeoffs when hardware has multiple functions. For example, a seat cushion that did not have to be a flotation device could be made of a wider variety of materials and could be made more comfortable to sit on.
Here’s where software and manufacturing design differ. In software, polymorphism doesn’t require tradeoffs as far as the function of the object goes. Notice in the shape example, that during run time of the code, the shape object will always be either a circle or a square—a distinct object with only one purpose. The shape object is never actually created in software, but used as an abstract reference. With physical objects, in contrast, an artifact needs to be two things at once. The tradeoffs are evident in the physical object, where in software, there is no tradeoff in the objects themselves.
Polymorphism does have an expense associated with it and should be used only when you need different functions in different contexts. The base functionality should be the same in both contexts—to draw a shape, to drive a vehicle, to lift up a person, to power a tool.
But overall, polymorphism is a powerful design pattern, popular in software, that can be used in larger systems to build in flexibility in product design. I believe this principle will be increasingly useful in the design push to build smaller, cheaper, better products for our customers. It may also become more useful as one moves to more abstract levels of system design such as axiomatic design.