Skip to main content

Object-Oriented Programming

The programmer in the illustration is taking "object-oriented" programming very literally...

If we were to sum up the purpose of Object-Oriented Programming (OOP) in a single sentence, it would be: OOP breaks down large programs into smaller, self-contained modules to construct a system that is both flexible and stable. Flexibility means we can add new features at any time; stability means that adding these new features does not require altering existing modules.

As software grows in scale, managing complexity becomes our greatest challenge. While procedural and functional programming offer excellent modularization mechanisms, OOP provides an intuitive and powerful paradigm for managing complex state and modeling real-world business logic.

The core idea of OOP is to bundle data (state) and the behaviors (methods) that operate on that data into unified entities called objects. This approach reduces coupling between components, helping us design systems that are both resilient and adaptable. Flexibility is achieved by extending functionality through inheritance and polymorphism, while stability is maintained through encapsulation, which shields internal logic and minimizes the side effects of code modifications.

Program Module Division​

In procedural programming, a program is viewed as a collection of sequential steps, procedures, or functions. Execution flow is controlled using conditionals, loops, and function calls. When designing a procedural system, the natural approach is top-down design.

For instance, if a program is designed to run a test suite, a designer first outlines the overall framework, breaking the system down into several high-level procedures: data collection, data analysis, data display, and data storage. The program's entry point simply calls these sub-functions in sequence. Next, these sub-functions are designed and subdivided further. For example, data collection might be split into: opening a hardware device, configuring it, reading raw data, and closing the device.

While this decomposition naturally creates a structured hierarchy, scaling the codebase introduces challenges. As codebases grow, developers look for opportunities to reuse modules across different parts of the application or even in entirely separate projects.

As software grows, it requires collaboration across large teams. No single developer can understand the entire codebase in detail. To save time, programmers reuse existing modules, sometimes in creative or unexpected ways. Furthermore, business requirements change constantly. Instead of redesigning a system from scratch, developers patch and adapt existing components.

Over time, the clean, tree-like dependency hierarchy originally designed begins to degrade. The relationships between modules become chaotic and tightly coupled, making it hard for anyone to predict where or how a specific component is being used.

This chaos makes modifying modules risky. If a developer fixes a bug or refactors a module to meet a new requirement, they might break other parts of the application that depend on that module's original behavior. Because the module's users are unaware of the internal changes, tracking down the resulting regression errors can be incredibly time-consuming.

To mitigate the risks of module reuse and combat software decay, we need a better design methodology. Module interfaces must be explicit and self-documenting. We must be able to restrict access to a module's internals, exposing only safe, stable interfaces while hiding implementation details that are subject to change. Modules should also be easy to extend, optimize, and upgrade. Object-Oriented Programming provides an elegant solution to these challenges.

Classes and Objects​

The physical world is made of entities. A room contains tables, chairs, and computers. Many of these entities share characteristics and can be grouped into a class. For example, Human is a class, and the individual Ruan Qizhen is an entity within that class. All humans share common traits, such as walking upright, speaking, and thinking.

Since software is built to model and solve real-world problems, programming adopts a similar categorization. For instance, in an enterprise management system, employees like Zhang San and Li Si share common attributes—such as names, genders, and ages—even though their specific values differ.

An object (or instance) is a specific entity that belongs to a class. In our example, the individual employee Zhang San is an object instantiated from the Employee class.

Attributes (also referred to as data or variables) represent the static properties or state of an object. For example, Employee objects have attributes like name, gender, and age.

Methods (which are simply functions defined within a class) describe the dynamic behaviors or actions an object can perform. For example, an Employee object might have methods like work_overtime() or receive_salary().

Object-Oriented Programming Design​

Object-Oriented Programming shifts the focus from writing sequential procedures to designing self-contained objects as the fundamental building blocks of an application. This structural change dramatically improves code reusability, flexibility, and scalability.

OOP is characterized by three core pillars: encapsulation, inheritance, and polymorphism.

Encapsulation (Data Abstraction)​

Encapsulation bundles related data and behaviors into a single, self-contained unit (a class).

External code can only interact with this unit through a clearly defined public interface (public methods). The internal implementation details and state (private data) are hidden and protected, acting like a black box. By shielding the internals, we can modify or refactor the class's inner workings without breaking the external code that depends on it, significantly enhancing system stability.

For example, if we are building a simulation of animal life, we can abstract their properties into an Animal class. The public interface might expose attributes like name or age, and methods like eat() or make_sound(). However, the class can also have internal attributes and helper methods. When an external program calls the move() method, the class internally processes the movement based on a private _number_of_legs attribute. External code cannot modify or access _number_of_legs directly, preventing invalid states (like setting a dog's legs to -5).

Inheritance​

Inheritance allows us to define a new class (a subclass or derived class) based on an existing class (a parent class, base class, or superclass). The subclass automatically inherits the attributes and methods of the parent class, while allowing us to override behaviors or define unique characteristics. This reuse prevents code duplication and mirrors real-world taxonomies.

For instance, puppies and chicks are both animals. They share core biological functions, making them good instances of a general Animal class. However, dogs have unique behaviors that don't apply to chickens. To represent this, we can define a Dog class that inherits from Animal.

Because Dog inherits from Animal, it instantly gains access to all public Animal attributes and methods. We then only need to write dog-specific behaviors, such as guard_house(), while a Chicken subclass might implement lay_egg().

We refer to a class's ancestors (parents, grandparents, etc.) as ancestor classes, and its descendants (children, grandchildren, etc.) as descendant classes.

Polymorphism (Dynamic Binding)​

Polymorphism (originally a biological term referring to an organism or gene having various forms) allows different objects to respond to the same method call in their own unique way. This lets us use a single, unified interface to interact with distinct object types.

Even though subclasses inherit methods from a common parent class, they can override those methods to implement distinct behaviors. When we invoke the method on a collection of mixed objects, each object runs its own version of the method. Polymorphism allows us to write code that interacts with the parent class interface, ignoring subclass differences at design time.

For example, suppose the Dog and Chicken subclasses both inherit a make_sound() method from Animal. We override the method in each subclass: dogs bark, chickens cluck. If our application needs to iterate through a list of animals and make each of them vocalize, we can treat every item in the list as a generic Animal and call make_sound().

The programmer writing the loop does not need to know or check whether a given animal is a dog or a chicken. At runtime, Python automatically inspects the actual object type and dispatches the call to the correct method (a process known as dynamic binding). If we later add a Duck class with a quacking behavior, the loop continues to work perfectly without requiring any modifications.