Everyone likes beautiful design. I do, too. But, the use of design patterns is not just to make something look good. Everything we do should have a purpose.

The GoF classified object-oriented design patterns as creational, structural, and behavioral. For Julia, let's take a different perspective and classify our patterns by their respective software quality objectives as follows:

• Reusability
• Performance
• Maintenance
• Safety

Let's understand each of these in the following sections.

People often talk about top-down and bottom-up approaches when designing software.

The top-down approach starts with a large problem and breaks it down into a set of smaller problems. Then, if the problems are not small enough, as discussed when we looked at the Single Responsibility Principle, we further break down the problem into even smaller ones. The process repeats and eventually the problem is small enough to design and code.

The bottom-up approach works in the opposite direction. Given domain knowledge, you can start creating building blocks, and then create more complex ones by composing from these building blocks.

Regardless of how it is done, eventually there will be a set of components that work with each other, thereby forming the basis of the application. 

I like the metaphor. Even a 5-year old child can build a variety of structures using just several kinds of Lego block. Imagination is the limit. Do you ever wonder why it is so powerful? Well, if you recall, every Lego block has a standard set of connectors: one, two, four, six, eight, or more. Using these connectors, each block can plug into another block easily. When you create a new structure, you can combine it with other structures to create even larger, more complex structures.

When building applications, the key design principle is to create pluggable interfaces so every component can be reused easily.

The following are important characteristics of reusable components:

• Each component serves a single purpose (the S in SOLID).
• Each component is well defined and ready for reuse (the O in SOLID).
• An abstract type hierarchy is designed for parent-child relationships (the L in SOLID).
• Interfaces are defined as a small set of functions (the I in SOLID).
• Interfaces are used to bridge between components (the D in SOLID).
• Modules and functions are designed with simplicity in mind (KISS).

Reusability is important because it means we can avoid duplicated code and wasted effort. The less code we write, the less work we need to do to maintain software. That includes not just the development effort but also the time testing, packaging, and upgrading. Reusability is also one of the reasons why open source software is so successful. In particular, the Julia ecosystem contains many open source packages and they tend to borrow functionalities from each other.

Next, we will discuss another software quality objective—performance.

The Julia language is designed for high-performance computing. It does not come for free, however. When it comes to performance, it takes practice to write code that is more compiler-friendly, thus making it more likely to translate the program into optimized machine code.

For the past few decades, computers have seemed to become faster and faster every year. What used to be performance bottlenecks are more easily solved using today's hardware. At the same time, we are also facing more challenges due to the explosion of data. A good example is the field of big data and data science. As the amount of data grows, we need even more computing power to handle these new use cases.

Unfortunately, the speed of computers has not grown as rapidly as it did in the past. Moore's Law states that the number of transistors on a microchip doubles roughly every 18 months, and since 1960 it has been correlated with the growth in CPU speed. However, it is well known that Moore's Law will no longer be applicable soon due to a physical limitation: the number of transistors that can be fitted to a chip and the precision of the fabrication process.

In order to address today's computational needs, especially in the world of artificial intelligence, machine learning, and data science, practitioners have been gearing toward a scale-out strategy that utilizes multiple CPU cores across many servers, and looking at exploiting the efficiency of GPUs and TPUs.

The following are characteristics of high-performance code:

• Functions are small and can be optimized easily (S in SOLID).
• Functions contains simple logic rather than complex logic (KISS).
• Numeric data is laid out in contiguous memory space so the compiler can fully utilize CPU hardware.
• Memory allocation should be kept to a minimum to avoid excessive garbage collection.

Performance is an important aspect of any software project. It is particularly important for data science, machine learning, and scientific computing use cases. A small design change can make a big difference—depending on the situation, it could possibly turn a 24-hour process into a 30-minute process. It could also give users real-time experience when using a web application rather than a please wait... dialog.

Next, we will discuss software maintainability as another software quality objective.

Software can be maintained more easily when it is designed properly. Generally speaking, if you are able to effectively use the design principles listed previously (SOLID, KISS, DRY, POLA, YAGNI, and POLP), then your application is more likely to be well architected and designed for long-term maintenance.

Maintainability is an important ingredient for large-scale applications. A research project from graduate school may not last long. On the contrary, an enterprise application may last for decades. Recently, I heard from a colleague that COBOL is still in use and COBOL programmers are still making a good living.

We often hear about technical debt. Similar to monetary debt in real life, technical debt is something that you must pay for whenever code is changed. And the longer the technical debt stays in place, the more effort you have to spend. 

To understand why, consider a module that is bloated with duplicate code or unnecessary dependencies. Whenever a new functionality is added, you have to update multiple parts of the source code, and you have to perform regression testing for a larger area of the system. So, you end up paying (in terms of programming time and effort) for the debt every time the code is changed until the debt is fully repaid (that is, until the code is fully refactored).

The following are characteristics of maintainable code:

• No unused code (YAGNI).
• No duplicate code (DRY).
• Code is concise and short (KISS).
• Code is clear and easy to understand (KISS).
• Every function has a single purpose (the S in SOLID).
• Every module contains functions that relate to and work with each other (the S in SOLID).

Maintainability is an important aspect of any application. When designed properly, even large applications can be changed frequently and easily without fear. Applications can also last a long time, reducing the cost of the software.

Next, we will discuss software safety as another quality objective.

Applications are expected to function correctly. When an application malfunctions, there could be undesired consequences and some of those could be fatal. Consider a mission-critical rocket-launch subsystem used by NASA. A single defect could cause the launch to be delayed; or, in the worst-case scenario, it could cause the rocket to explode in mid-air.

Programming languages are designed to allow flexibility but at the same time provide safety features so software engineers can make fewer mistakes. For example, the compiler's static type checking ensures that the correct types are passed to functions that expect those types. In addition, most computer programs operate on data, and as we know, data is not always clean or available. Hence, the ability to handle bad or missing data is an important software quality. 

Some characteristics of safe applications follow:

• Each module exposes a minimum set of types, functions, and variables.
• Each function is called with arguments such that the respective types implement the expected behavior of the function (the L in SOLID; POLA).
• The return value of a function is clear and documented (POLA).
• Missing data is handled properly (POLA).
• Variables are limited to the smallest scope.
• Exceptions are caught and handled accordingly.

Safety is one of the most important objectives here. An erroneous application can cause major disasters. It can even cost a company millions of dollars. In 2010, Toyota recalled over 400,000 of its Prius hybrid cars due to a software defect with the Anti-lock Braking System (ABS). In 1996, the Ariane 5 rocket launched by the European Space Agency exploded just 40 seconds after launch. Of course, these are only a few more extreme examples. By utilizing best practices, we can avoid getting into these kinds of embarrassing and costly incidents.

Now, we understand the importance of software design principles and software quality objectives.