Benefits of Interface-Oriented Programming

Its significance in projects:

In traditional project development, customer requirements often change. If interface-oriented programming is not adopted, developers must constantly rewrite existing business code. Modifying code can introduce new bugs, and such changes often affect all classes that depend on the business logic, requiring widespread modifications and reducing overall system stability.

To minimize the impact of these changes, developers may be forced to compromise with the current system structure, resulting in lower code quality and reduced stability. When this situation accumulates over time, the system may develop unpredictable errors, messy code structure, and poor readability. Eventually, new developers cannot understand the code easily, maintenance costs continue to rise, and the project may even fail.

In a project, an interface represents a layer of business logic.

Interface-oriented programming means extracting business requirements first and defining them as interfaces. The actual business implementation is completed through concrete implementation classes. When requirements change, developers only need to create a new implementation class and switch the implementation via configuration (such as in the Spring Framework), without rewriting existing code. This greatly reduces system impact and risk.

Projects based on interface-oriented programming have clear business logic, readable code, strong extensibility, and high maintainability. Even if development staff changes, new members can quickly get up to speed. From a company perspective, the value is even greater.

Its significance in Java:

Java itself is a continuously evolving language. Its system APIs form a massive, interdependent ecosystem. Without interfaces, if only concrete implementation classes were used, any API change would cause instability throughout the entire system.

Once an API is released in the JDK, it becomes a commitment and cannot be modified. Even if the original API design contains flaws (for example, java.util.Properties is often cited as a problematic design), it must still be preserved. This is why Java provides deprecated methods that are discouraged but cannot be removed.

Furthermore, Java is a cross-platform language. To support execution across different platforms, platform-specific operations must be abstracted into interfaces, with separate implementations provided for each operating system.

Reflection in design patterns:

The Open–Closed Principle in design patterns emphasizes being open for extension but closed for modification—an idea fundamentally based on interfaces.

Another key principle is the Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions (from Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin).

By separating business logic from concrete implementations, interface-oriented programming reduces coupling between classes. When changes occur, existing systems do not need to be modified—new implementation classes can simply be added, eliminating concerns that new changes will impact other modules.

In essence, an interface serves as a contract that coordinates the relationship between designers, implementers, and callers.

Therefore, “interface-oriented programming” can be understood as follows:

Only when both implementers and callers follow the principle of interface-oriented programming can the designer’s coordination objective truly be achieved.

A classic example of this concept is JDBC.

Advantages:

Interfaces separate abstraction from implementation, making them ideal for collaborative team development.

They primarily enable loose coupling, facilitating future upgrades and system expansion.

Disadvantages:

Design becomes more difficult. Interfaces must be defined before implementations exist, and once an interface changes, the entire system can be affected—this is why design is often harder than implementation.

That’s also why engineers who design interfaces are usually paid more!