Whereas System Design deals with system architecture at a high-level, Object Oriented Design (OOD) represents the other end of the spectrum.

 

OOD involves implementing specific modules or components and their classes within a more extensive system.

 

We can think of OOD similarly to building the engine of a Formula 1 race car. If the entire car is a distributed system, then the engine's design would be considered a low-level process within that system. 

 

When I first started interviewing for software engineer positions, Low-Level OOD interviews were the only type of design interview you'd find yourself in. System Design and scalable systems weren't as integral as they are today because large-scale distributed systems were relatively uncommon.

 

The OOD interview will primarily measure two criteria: 

1. Can you design a component that successfully interacts with other components in the system?

2. Can you use design patterns to create this component efficiently?

 

Understanding the various design patterns of OOD should be a primary focus of your preparation for the low-level design interview.

 

“Design Patterns: Elements of Reusable Object-Oriented Software” (1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (collectively known as the "Gang of Four") is considered a landmark text in the field of object-oriented design. It helped popularize the use of design patterns at a time when object-oriented design was reaching new heights of popularity. 

 

This book highlighted 23 fundamental design patterns of OOD organized into three categories: creational, structural, and behavioral patterns. 

 

1. Creational patterns deal with the process of object creation and are used to abstract the process of object creation.

2. Structural patterns deal with class and object composition. These patterns provide ways to organize or combine classes and objects to form larger structures. 

3. Behavioral patterns focus more on object interaction and how objects communicate with each other. These patterns deal with how responsibilities are delegated across different objects. 

 

Each category represents a set of design patterns meant to solve a specific type of object-oriented design problem. By using these patterns, developers can significantly improve their software's coherence, modularity, and maintainability. 

 

Of the 23 design patterns, these are the most frequently used in technical design interviews:

• Singleton: Restricts the instantiation of a class to a single object.

• Factory: Doesn't require the use of a constructor to create objects (aka, the `new` keyword).

• Constructor: Uses the constructors present in the class to create specific types of objects.

• Iterator: Iterates a collection of objects without exposing the underlying form.

• Facade: Simplifies a client’s interaction with the system by hiding the underlying complex code.

• Adaptor: Allows an object to cooperate with a class that has an incompatible interface.

• Visitor: Allows new operations to the objects without changing the structure of the objects themselves.

 

Ultimately, the best pattern to use depends on the question asked. For example, if your software is generating IDs for your desktop app, you only want a single class generating those IDs, especially if you have more than one thread working off that class. The Singleton pattern is extremely relevant here as it ensures that each process in the software will have only one instance of your class.

 

OOD is the oldest among the stages of tech design interviews, but it is not going away anytime soon. System Design can only be effective with individual processes also being optimized. Nobody will use a web app if their web browser software provides a bad user experience. Scalability only matters if customers want to stick around in the first place.