5 Object-Oriented Principles

5 Principles #

1. SRP (Single Responsibility Principle)
2. OCP (Open-Closed Principle)
3. LSP (Liskov Substitution Principle)
4. ISP (Interface Segregation Principle)
5. DIP (Dependency Inversion Principle)

SRP Single Responsibility Principle #

A class should have only one responsibility.

• Since the definition of "responsibility" is ambiguous, using "change" as the criterion for responsibility can be useful in design.
• If a class groups together only the functionalities affected when a change occurs for a certain role, it can be seen as a design applying the SRP principle, as it's a collection of functionalities with the same responsibility.
• Thus, if the ripple effect on the application is small when there is a change, it can be considered that this principle has been well followed.

OCP Open Closed Principle #

The Open-Closed Principle can be explained by the principles of high cohesion and low coupling.

High Cohesion #

High cohesion means that a module or class focuses on a single responsibility or concern. Because objects are designed based on the same responsibility and concern, even if a change occurs in an object, its impact on other parts is limited.

Low Coupling #

Objects or modules with different responsibilities and concerns should maintain low coupling. This is a more sensitive principle than high cohesion.

• Coupling refers to the degree to which one object requires changes in other related objects when it undergoes a change.
• That is, low coupling can be seen as a state where a change in one module does not propagate change requests to other modules and objects.

Elsewhere, the Open-Closed Principle is also described as being open for extension and closed for modification.

Open for extension? #

• This means ensuring the extensibility of a module.
• It's because code can be flexibly added or modified when new changes occur.

Closed for modification? #

• Directly modifying an object should be restricted. If functionality needs to be added or modified by directly changing the object, the application cannot flexibly respond to new changes.
• This can lead to increased maintenance costs and is not considered an object-oriented design.
• Therefore, the design should allow changes to be applied without directly modifying the object. This is inferred to be why it's expressed as closed for modification.

As a result, OCP is interpreted as meaning abstraction. By abstracting objects, a flexible structure that is open for extension and closed for modification can be created.

To implement OCP, DI and IoC are necessary.

LSP Liskov Substitution Principle #

Objects should be replaceable with instances of their subtypes without altering the correctness of the program.

• Subclasses must adhere to the interface contract. This principle is necessary for supporting polymorphism; if you want to trust and use an interface's implementation, LSP is required.
• If you use an interface's method, any implementation should behave as expected by the caller, regardless of the internal logic.

interface Calculator {
  int add(int num1 , int num2);
}

When add() is called from the caller, it's expected to sum the input parameters and return the result, even without knowing the internal logic. Therefore, interface implementations and subclasses should be designed to adhere to this contract.

ISP Interface Segregation Principle #

It is better to have multiple client-specific interfaces than one general-purpose interface.

• To illustrate the statement "a driver drives a car" as a relationship between objects, it means separating interfaces for the car and for the driver.
• Then, a driver can be a taxi driver or an Uber driver. A car can be a bus or a taxi, thus increasing extensibility.

Dependency Inversion Principle #

Programmers should depend on abstractions, not concretions. That is, depend on interfaces, not implementation classes.

• Taking a play as an example, it can be illustrated with roles and actors. In this case, a play should be planned focusing on the roles rather than specific actors.
• If the play depended on a specific actor, and that actor couldn't perform due to schedule conflicts or condition on the day, the play would inevitably face difficulties. Therefore, a play should depend on the roles, not the actors.

Designing the dependency relationship this way means that even if changes occur to the LottoNumberGenerator object or if the object needs to be deleted, the Lotto class will not require direct code changes.