1 year ago

Orthogonality

Orthogonality, how many of you have heard this term? Unless you've read works like The Pragmatic Programmer, you'd more than likely come across this terminology in a mathematics class.

In mathematics, orthogonality is the relation of two lines at right angles to one another (perpendicularity).

In the above image, the lines A and B are orthogonal to each other. Now how might this be applied to programming? Lines that are orthogonal to each other never affect nor cross paths with each other. Meaning, each line is independent of the other. This concept can be applied to programming, where systems within your application (or even at the code-level) are independent of one another; changing one component does not affect another - it can continue on its own path (just like the lines in the above image).

Let's zoom out and look at a generalized example of how this might be laid out. Let's say you're developing a CMS, and you need to create a blog where posts can be tagged and categorized, as well as accept user comments; you also need a way to create simple pages with text. This is great! We have our scope and can begin building these components out, and you come out with a blog and a pages component:


Blog Component

Blog posts can be tagged and categorized, as well as accept user comments.

Pages Component

Simple text pages.


But wait, after you finished building these two components you come to the conclusion that you also want users to be able to leave comments on your pages as well. Now you need to build the same functionality into your pages component that you already have available in your blog. This in short results in a duplication of code and functionality, which goes against a well known principle of software development - DRY (Don't Repeat Yourself) as well as being a gateway to the Cut-And-Paste Programming AntiPattern.

Both of those are bad in coding land.

The right solution to this, is to decouple the comment system from your blog component into an abstraction as its own component. This way, instead of duplicating the commenting system between the two components, they both can utilize the comments component.


Comments Component

Gives the ability to accept and display user comments.

Blog Component

Blog posts can be tagged and categorized. Utilizes the comments component.

Pages Component

Simple text pages. Utilizes the comments component.


Now the comment component can be developed and managed on its own, while the blog and pages components are fundamentally untouched while sharing common functionality, and vice versa.

I like to look at these as hexagonal tiles that can be pieced together to form new components (forgive my lacking Gimp skills in the below image, I tried).

If you haven't noticed, the terminologies decouple, abstract, and orthogonal all have similar meanings that roughly translates to independence. We want to be able to take two separate elements (the numbers 4 and 5 for example) and combine them to get new functionality that may not have been previously envisioned (4 + 5 = 9; 9 being a new number to us that was previously unknown). This concept is also known as the bridge design pattern within object-oriented design.

In Conclusion

This is a concept and way of thinking that can be applied within any programming language. When building out an application, think of the various components and requirements that make it up. Can certain things be abstract so they can be utilized through out your application without duplicating their functionality? There are some pretty common components that fit the orthogonal way of thinking easily such as the user comments component in our CMS example earlier. Can something like a blog and pages component be broken down into abstract components where they share common functionality? It may feel a little weird to try and extract shared abstract components out from something like a blog and pages component as they're commonly always developed a certain way across a multitude of different platforms. The key here is thinking outside of the box and looking at things at a different angle, as they can give insight into how things are built leading to possible better solutions.

Further Reading