Orthogonality in Software Engineering
Return to Computer Science Topics
Orthogonality
- Snippet from Wikipedia: Orthogonality (programming)
In computer programming, orthogonality means that operations change just one thing without affecting others. The term is most-frequently used regarding assembly instruction sets, as orthogonal instruction set.
Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language. It is associated with simplicity; the more orthogonal the design, the fewer exceptions. This makes it easier to learn, read and write programs in a programming language. The meaning of an orthogonal feature is independent of context; the key parameters are symmetry and consistency (for example, a pointer is an orthogonal concept).
An example from IBM Mainframe and VAX highlights this concept. An IBM mainframe has two different instructions for adding the contents of a register to a memory cell (or another register). These statements are shown below:
A Reg1, memory_cell AR Reg1, Reg2
In the first case, the contents of
Reg1are added to the contents of a memory cell; the result is stored inReg1. In the second case, the contents ofReg1are added to the contents of another register (Reg2) and the result is stored inReg1.In contrast to the above set of statements, VAX has only one statement for addition:
ADDL operand1, operand2
In this case the two operands (
operand1andoperand2) can be registers, memory cells, or a combination of both; the instruction adds the contents ofoperand1to the contents ofoperand2, storing the result inoperand1.VAX's instruction for addition is more orthogonal than the instructions provided by IBM; hence, it is easier for the programmer to remember (and use) the one provided by VAX.
The Revised Report on the Algorithmic Language Algol 68 had this to say about "Orthogonal design":
The number of independent primitive concepts has been minimized in order that the language be easy to describe, to learn, and to implement. On the other hand, these concepts have been applied "orthogonally" in order to maximize the expressive power of the language while trying to avoid deleterious superfluities.
The design of C language may be examined from the perspective of orthogonality. The C language is somewhat inconsistent in its treatment of concepts and language structure, making it difficult for the user to learn (and use) the language. Examples of exceptions follow:
- Structures (but not arrays) may be returned from a function.
- An array can be returned if it is inside a structure.
- A member of a structure can be any data type (except void, or the structure of the same type).
- An array element can be any data type (except void).
- Everything is passed by value (except arrays).
Though this concept was first applied to programming languages, orthogonality has since become recognized as a valuable feature in the design of APIs and even user interfaces. There, too, having a small set of composable primitive operations without surprising cross-linkages is valuable, as it leads to systems that are easier to explain and less frustrating to use.
On the other hand, orthogonality does not necessarily result in simpler systems, as the example of IBM and VAX instructions shows — in the end, the less orthogonal RISC CPU architectures were more successful than the CISC architectures.
In software engineering, a system is considered orthogonal if changing one of its components changes the state of that component only.
For instance, consider a program with three variables: a, b, and c. Changing the value of a should not change the value of b or c, provided they are independent.
This property is particularly critical in debugging a program since one relies on narrowing down the number of moving parts of a program to identify the root cause of the problem.
See the following quote from Eric S. Raymond’s “Art of UNIX programming”:
Orthogonality is one of the most important properties that can help make even complex designs compact. In a purely orthogonal design, operations do not have side effects; each action (whether it’s an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling. Orthogonality is a software design principle for writing components in a way that changing one component doesn’t affect other components. It is the combination of two other principles, namely strong cohesion and loose coupling.
It's actually is a term borrowed from mathematics. For example, two lines are orthogonal if they are perpendicular. In software design, two components are orthogonal if a change in one does not affect the other.
Applying this concept to classes or other sections of code results in less coupling. To be orthogonal two classes cannot depend on each others implementation. They also cannot share global data. Changing the internals of one class does not affect the other class. Components should be independent and have only a single responsibility.
Consider a method that reads a list of numbers from a file and returns them in sorted order. Now the requirements change and the numbers are in a database. Modifying this method to access the database would cause client code to change. If this were two different methods, then a new source would not affect the sorting method. Only the client code would have to know the source of the numbers.
Strong Cohesion Inside a software component, code should be strongly connected. This is an indication that the code is correctly divided.
If a component had two or more relatively disconnected parts, that may indicate that those parts should be in a different component, or on its own.
Loose Coupling Between software components, there should be few connections. If two components are strongly coupled, it may indicate that they need to be one component, or that they need to be differently divided into more components.
https://www.freecodecamp.org/news/orthogonality-in-software-engineering
Orthogonality in Computer Programming Last updated: March 18, 2024
Written by: Nikhil Bhargav
Reviewed by: Milos Simic Programming 1. Introduction
In this tutorial, we’ll study orthogonality and its application in computer programming.
The word ‘orthogonal’ comes from two ancient Greek words: ‘orthós’ meaning upright and ‘gōnía’ meaning angle.
It finds wide application in many areas such as mathematics, physics, signal processing, communication, computer programming, and even arts. But the concept of orthogonality means different things in each field.
In computer science, the general idea behind orthogonality is the ability to change one thing without any unseen effect on other things. In other words, it’s about the independence of components in a larger system.
2. Orthogonality in Programming Languages
We measure a language’s orthogonality by the degree to which we can combine its built-in constructs without side effects. In an ideally orthogonal language, no construct or language feature we use has any effect on how we use any other construct or a feature.
Based on this, a programming language belongs to one of the following three classes:
Fully orthogonal Partly or quasi-orthogonal Non-orthogonal The following diagram shows this classification with some examples of each class:
orthogonality in programming languages 2.1. Fully Orthogonal Languages
A programming language is fully orthogonal if we can combine the majority of its constructs in many ways without any side effects. We consider Scala a fully orthogonal language.
For example, in Scala, we can use functions just like all other objects: as local variables, fields, or parameters to other functions. In doing so, we experience no side effects. For instance, passing a function as an argument doesn’t invoke it. Scala is orthogonal in both object-orientated programming and functional programming paradigms. So, we can freely adopt both of these frameworks in Scala without worrying about any side effects.
2.2. Quasi-Orthogonal Languages
We say a programming language is quasi or partly orthogonal if many of its basic constructs, but not the majority thereof, can be combined in only a few ways without side effects. Java and Python are such languages.
In Python, we can combine built-in data structures such as lists and sets to build advanced data structures. However, the constructor list doesn’t have side effects, whereas set does. For example, applying set to a list removes all duplicate values from the list. So, list(set(x)) isn’t the same as set(list(x)). As a result, those two built-in types aren’t orthogonal.
In Java, the accessibility specifiers such as public and private are completely orthogonal to the specifier static. However, the way variables are stored depends on their types. So, specifying a variable’s type has side effects. For example, in the following code, x is a value on the stack whereas y is a reference to the object’s content in the heap:
int x; /* x is a value */ MyClass y; /* y is a reference */ Copy 2.3. Non-orthogonal Languages
We categorize a programming language as nonorthogonal when most of its constructs can’t be combined in many ways without any side effects.
In simple terms, non-orthogonality means there are exceptions to the general language rules and syntax.
For example, we consider C++ as a non-orthogonal language.
In C++, we can declare an object to be of any fundamental type except void, but this doesn’t apply to templates. For example, for the following template declaration, we need to explicitly cast T as void for it to work:
template<typename T> T f() {
...} T = void; Copy That doesn’t mean there’s no orthogonality in C++. Instead, only a few built-in constructs are orthogonal to one another.
Another example is C. For instance, it has two built-in data structures: arrays and structs. We can return a struct from a function in C, but cannot return an array from a function. Similarly, a struct can have members of any type except void or a structure of the same type, arrays can’t be of type void, and so on.
2.4. Consequences of Orthogonality
A very high level of orthogonality makes the language simple and easy to learn.
However, it can result in many ways to combine language constructs. Usually, that makes the compiler or interpreter very complex.
In addition to this, the features that are back-compatible should be orthogonal, i.e., it shouldn’t matter which version of a feature we use. As a result, the development of such languages is more complex.
3. Orthogonality in Software Design
Orthogonality is one of the most important requirements to make any software design 3C (Complete, Concise, Correct) compliant. A design or an architecture is orthogonal if and only if its operations don’t have side effects or after-effects.
So, every action, such as an API call, a callback, invocation of a background thread, or a language operation, changes just one thing without affecting others.
Let’s say we have an authentication server and 3 client applications. Orthogonality would mean the authentication request generated by one client are handled by the server without having any effect on the requests sent by other clients. In essence, orthogonal systems have one and only one way to change any property of their underlying subsystems.
As a result, orthogonality in software design reduces testing and development time because it’s easier to verify designs that neither cause side effects nor depend on each other’s actions.
3.1. Example of an Orthogonal System
Let’s consider a system having the following three parts:
Backend Database Frontend Frontend gives a user interface for the end user to interact with the system. The database stores all the data associated with the users. The backend implements all the services for the user:
Orthogonal Example Let’s say the user wants to do an advanced search in his view history. Here, we can change the UI interface with new screens without affecting both the background search service and the database. We can also switch the database from Oracle to MySQL without affecting the UI and backend (minimal changes to write interface code). Furthermore, we can change the underlying search algorithm in the backend without affecting both UI and Database.
3.2. Example of a Non-Orthogonal System
Let’s consider the same system as above but with one difference. The backend uses a database’s stored procedure to carry out an advanced search while making queries. So the backend search service acts as a wrapper around the database’s stored procedure doing an advanced search:
Non-orthogonal Example In this case, we cannot replace the database without affecting the backend and there is no clear interface between the two. Any change in the database will have an effect on the entire system.
4. Orthogonality in Data Storage
From a data storage point of view, we usually value persistent and fault-tolerant systems. The length of time data is kept intact in a storage system is called its persistence.
In the storage domain, orthogonal persistence refers to a situation where a developer can fetch and process data irrespective of its storage time. In other words, the length of time data has been kept in orthogonal storage doesn’t affect the way we handle it.
5. Conclusion
In this article, we talked about orthogonality in computer programming. Orthogonality is a relationship between two things such that they do not affect one another.
Orthogonal systems ensure that effects of modification of one part of the system neither create nor propagate any side effects to other parts of the system. That way, communication between different components of the system is strictly controlled by well-defined interfaces.
https://www.baeldung.com/cs/orthogonality-cs-programming-languages-software-databases