Object-Oriented Design

Software Engineering; Programming Language; Computer Science

Object-oriented design (OOD) is an approach to software design that uses a process of defining objects and their interactions when planning code to develop a computer program. Programmers use conceptual tools to transform a model into the specifications required to create the system. Programs created through OOD are typically more flexible and easier to write.

Object-oriented design (OOD) was developed to improve the accuracy of code while reducing software development time. Object-oriented (OO) systems are made up of objects that work together by sending messages to each other to tell a program how to behave. Objects in software design represent real-life objects and concerns. For example, in the code for a company's human resources website, an object might represent an individual employee. An object is independent of all other objects and has its own status. However, all objects share attributes or features with other objects in the same class. A class describes the shared attributes of a group of related objects.

OOD typically follows object-oriented analysis (OOA), which is the first step in the software development process when building an OO system. OOA involves planning out the features of a new program. OOD involves defining the specific objects and classes that will make up that program. The first OO language, Simula, was developed in the 1960s, followed by Smalltalk in 1972. Examples of well-known OO programming languages include Ruby, C++, Java, PHP, and Smalltalk.

OOD consists of two main processes, system design and object design. First, the desired system's architecture is mapped out. This involves defining the system's classes. Using the example of a human resources website, a class might consist of employees, while an object in that class would be a specific employee. Programmers plan out the essential attributes of a class that are shared across all objects within the class. For example, all employees would have a name, a position, and a salary. The class defines these attributes but does not specify their values. Thus, the class would have a field for the employee's name, and the individual object for a specific employee might have the name Joe Smith. All the objects within a class also share methods, or specific behaviors. For example, employee objects could be terminated, given a raise, or promoted to a different position.

Software engineers often follow a set of OOD principles identified by the acronym SOLID. These principles were first compiled by software engineer and author Robert Cecil Martin. The SOLID principles provide guidance for better software development, maintenance, and expansion. These principles are:

Single responsibility principle: Each class should have only one job.

Open-closed principle: A class should be open for extension but closed to modification (that is, it can be easily extended with new code without modifying the class itself).

Liskov substitution principle: Each subclass can be substituted for its parent class.

Interface segregation principle: Do not force clients to implement an interface (a list of methods) they do not use. Interfaces should be as small as possible. Having multiple smaller interfaces is better than having one large one.

Dependency inversion principle: High-level modules must not be dependent on low-level modules. Attempt to minimize dependencies between objects.

OOD is used to create software that solves real-world problems, such as addressing a user's needs when interfacing with an automatic teller machine (ATM). In this example, the software engineer first defines the classes, such as the transaction, screen, keypad, cash dispenser, and bank database. Classes or objects can be thought of as nouns. Some classes, such as transactions, might be further categorized into more specific subclasses, such as inquiry, withdrawal, deposit, or transfer.

Relationships between classes are then defined. For example, a withdrawal is related to the card reader, where the user inserts an ATM card, and the keypad, where the user enters their personal identification number (PIN). Next, classes are assigned attributes. For a withdrawal, these might be the account number, the balance, and the amount of cash to withdraw.

Successful development with OOD requires realistic expectations. Possible problems with this approach include insufficient training, which can lead to the belief that OOD will clear up every development delay, resulting in missed deadlines. Further issues arise when timelines are shortened in expectation of OOD's promise of speed. Thorough training is a programmer's best course to understanding the limitations and subtleties of OOD.

OOD has been a mainstay in software programming and will be used for years to come, but advances in technology will require programming languages that can deliver faster search results, more accurate calculations, and better use of limited bandwidth for the applications users increasingly rely upon. In addition, OOD is not the best choice for every requirement. It is appropriate for systems with a large amount of graphics, interfaces, and databases, but for simpler systems, task-oriented design (TOD) might be a better choice.

—Teresa E. Schmidt