Java Object-Oriented Programming (OOP)

Object-Oriented and Procedural-Oriented Programming

The early style of programming was procedural. As the name suggests, code is executed in order from the beginning as it is written. Because this is similar to how computers process instructions, execution is fast. However, as programs become larger and more complex, maintenance becomes difficult. Since input must follow a fixed order, it becomes difficult to produce the desired result if that order changes. For that reason, it is not suitable for large projects.

Object-oriented programming executes programs in logical units called objects, and it places more importance on the data used by a program than on the method of processing that data. Processing speed is relatively slower and design can take a lot of time, but code reuse is high and maintenance is easier. It is also easier to transition from analysis to design, so it is suitable for large projects.

Representative object-oriented programming languages include Java, C#, and Objective-C. Procedural languages include C, Pascal, and Fortran.

Object

An object can be described as a logical unit for managing information efficiently. An object consists of variables called attributes or fields, and methods that describe procedures for processing information.

Objects can represent things we commonly see in the real world, including objects, living things, and tangible or intangible entities. For example, a person has characteristics such as name, height, weight, and blood type, and performs actions such as eating, working, and studying. In programming terms, these characteristics and actions become attributes and methods.

Class

When writing a program, there are cases where you need to create objects of the same form. For example, suppose a company is building a human resources system. In that case, the attributes of many employees exist as the same type of data, and they will perform similar kinds of work. If you had to program separately to create objects for many employees, the program might need to change every time an employee’s personnel information changes.

For this reason, object-oriented programming uses a template, or class, to create objects of the same kind. Objects are created based on a class, and objects created from the same class all have the same attributes and methods.

In a human resources system, each employee has different values for attributes such as actual name and career history. This allows employees to be searched by name and assigned work with different levels of difficulty and roles.

Programming is often compared to constructing a building. Using that comparison, a class is like a building blueprint, and an object can be seen as the building created from that blueprint.

Inheritance

Inheritance means passing something from a higher level to a lower level, or receiving it from a higher level. In object-oriented programming, it similarly means that the attributes and methods of a parent object are passed down to a child object.

By using inheritance, code can be reused and duplication can be reduced. This also makes maintenance easier.

Encapsulation

An object has many attributes and many functions. From the perspective of someone using an object, there is no need to know exactly how a function is processed internally. Even without knowing how it is processed, the object can still be used without any problem. You only need to know what output is produced for a given input. This concept is encapsulation.

To explain it more simply, a person driving a car does not know every detail of how the engine works or how the wheels turn. However, the driver knows that the steering wheel can be used to change direction and that the accelerator and brake can be used to control speed. In the same way, a driver does not need to know the internal operating principles of the car to drive it. Encapsulation follows the same principle.

Encapsulation can be described as a protective mechanism that groups multiple attributes and functions inside a class and prevents arbitrary access from the outside. In Java, the foundation of encapsulation is the class. A class can distinguish between information that should be hidden (private) and information that should be exposed (public). Since users can access only the exposed information, information hiding becomes possible.

To summarize encapsulation:

  • It means grouping an object’s attributes and methods together and hiding the actual implementation details from the outside.
  • External objects do not know the internal structure of the object and can use only the attributes and methods that the object exposes.
  • Attributes and methods are encapsulated and protected so that the object is not damaged by incorrect external use.
  • Java uses access modifier keywords to decide whether encapsulated members should be exposed or hidden.

Polymorphism

Polymorphism means that one interface can be implemented differently and behave with different meanings depending on the situation. Overriding, which will be covered later, belongs to this concept.

In object-oriented programming, an abstract class is created first. A subclass inherits that abstract class and redefines, or overrides, the abstract methods defined in the parent abstract class. Suppose another subclass also inherits that abstract class and overrides the abstract method. Since each of the two subclasses redefines the abstract method in its own way, calling the method can result in different behavior.

For example, suppose there is an abstract class called Shape, and Triangle, Rectangle, and Circle are subclasses that inherit it. If Shape has an abstract method called draw() and each subclass inherits and overrides it, calling the same draw() method will produce a different shape depending on the subclass.

Polymorphism

The Shape class has an abstract draw method that can be used by subclasses to draw shapes. When this abstract method is overridden by the Triangle, Rectangle, and Circle classes, the method behaves differently depending on the inherited class that is called.

References