Of  Megaliths

The opposite of monolithic is of course polylithic.

These terms are used with megalithic architecture and structures. Rather than referring to something composed of a single stone, it is something composed of several or even of many stones. Wikipedia reports that:

The types of megalithic structures can be divided into two categories, the “Polylithic type” and the “Monolithic type”.

Examples of monolithic types include statues and standing stones, including Stonehenge. Examples of polylithic types include dolmens, cairns, and barrows.

The relevant Greek roots for these terms are:

• μέγα- (mega-) meaning great, big, large
• λίθος (lithos) meaning stone
• μόνο- (mono-) meaning single, one
• πολυ- (poly-) meaning several, many

---

Of  Software

Insofar as it can be applied to software design and architecture, one can see how it refers to something with many interchangeable pieces, not one giant program. The Unix philosophy encourages polylithic design, because it encourages small tools that each do one thing well but can be combined in many ways. Eric Raymond summarizes these in part as:

• Rule of Modularity: Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging complex code that is complex, long, and unreadable.
• Rule of Clarity: Developers should write programs as if the most important communication is to the developers, including him- or herself, whom will read and maintain the program rather than the computer. This rule aims to make code readable and comprehensible for whoever works on the code in future.
• Rule of Composition: Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.
• Rule of Separation: Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and back-end engine that interface communicates with. This rule aims to let policies be changed without destabilizing mechanisms and consequently reducing the number of bugs.
• Rule of Simplicity: Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.

There are other principles, but those are the most important ones. The polylithic design of Unix is what makes the command line (and shell scripts) so powerful, as Neal Stephenson so eloquently describes in his persuasive essay “In the Beginning . . . Was the Command Line”.

These principles of polylithic architecture can also be applied to object-oriented design, when you have a variety of coöperating, communicating classes that can be multiply combined in useful ways. One site describes this as:

Generally, a polylithic design is given when a [piece of] software provides a high count of different classes. Each class provides only a small amount of functionality. These separated classes are consolidated through several programming techniques like inheritance or generic concepts.

A lot of separation allow developers to change or manipulate existing functionality selectively. Furthermore, a high abstraction of objects forces developer to implement well thought out components which may also work correctly when other components have changed. Typically, this results in a clear, flexible, and elaborate architecture. Furthermore, the code of single classes is less complex.

When designing a highly interchangeable polylithic class system, the traditional subclass–superclass relationships can become at best onerous. For this reason, modern programming languages often resort to the highly acclaimed “C3” method resolution order, which essentially provides for breadth-first method resolution.

Instead of having merely a superclass above you in the inheritance graph, you also have a “next” class to the right of you, something more like a sibling or cousin class than a parent class. This often works better for these fancy polylithic class designs than can be achieved under the limitations of the old subclass–superclass setup. That’s because the interchangeability aspect is enhanced, so that you don’t have to go around deriving n² new classes just because you have n classes you want to interoperate with n other classes, and when you are limited to them interacting through a parent–child relationship instead of sibling (or cousin or uncle–nephew, etc.) relationship.

You might also wish to consider exploring mixins, duck typing, and role-oriented programming for more flexible approaches to polylithic object design.