OCP and code modification — what is actually closed?
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
No, OCP definitely doesn't mean you never modify existing code.
That's a common misunderstanding. What OCP actually says is that stable, well-tested code shouldn't need changes just to add new features. But there are plenty of legitimate reasons to modify code.
Bug fixes always require modifying code — that's how you fix bugs. If your UserService has a logic error, you edit it, you don't try to extend around it. Refactoring is another case.
If you're improving code readability or extracting methods for clarity, that modifies existing files, and that's healthy maintenance. Performance optimizations often modify existing code too. Security patches require immediate changes regardless of design principles.
OCP is really about feature additions. When you're adding a new payment method or a new discount type, that should happen by creating new classes, not by editing the existing payment processor. The principle is about making your design extensible so that most new features don't require touching stable code.
It's a design goal, not a rigid rule. The key is judgment. If you're fixing something broken or fundamentally changing requirements, modify the code.
If you're adding a variant of existing behavior and the design supports it, extend with new classes. OCP guides you to prefer extension where feasible, but it doesn't handcuff you.
OCP and code modification — what is actually closed
Direct Answer
No. OCP does not mean never touch existing code. It means stable, well-tested code should not need to change just to add new features. Bug fixes, refactoring, and performance improvements still require modifying code. The key is: adding a new feature should ideally be done by adding new code, not by editing already-working code.
Code Example
// Original implementation
@Service
class UserService {
private final UserRepository repository;
public UserService(UserRepository repository) {
this.repository = repository;
}
public void registerUser(String email, String password) {
var user = new User(email, password);
repository.save(user);
}
}
// Scenario 1: BUG FIX - modify existing code (OCP doesn't apply)
class UserService {
public void registerUser(String email, String password) {
if (email == null || email.isBlank()) {
throw new IllegalArgumentException("Email required");
}
var user = new User(email, password);
repository.save(user);
}
}
// Scenario 2: REFACTORING - modify for clarity (OCP doesn't apply)
class UserService {
public void registerUser(String email, String password) {
validateEmail(email);
var user = new User(email, password);
repository.save(user);
}
private void validateEmail(String email) {
if (email == null || email.isBlank()) {
throw new IllegalArgumentException("Email required");
}
}
}
// Scenario 3: FEATURE ADDITION - extend via new class (OCP applies)
interface UserRegistrationListener {
void onUserRegistered(User user);
}
class EmailVerificationListener implements UserRegistrationListener {
public void onUserRegistered(User user) {
// Send verification email - new behavior, zero changes to UserService
}
}
Common Mistakes & Pitfalls
- Treating OCP as absolute: Freshers read OCP and become afraid to touch any existing code, even for legitimate bug fixes. This leads to convoluted workarounds instead of straightforward fixes. Remember: OCP is about feature additions, not prohibiting all modifications.
- Over-engineering everything: Creating interfaces and abstract base classes for every class preemptively to satisfy OCP, even when no variation exists or is planned. This adds complexity without benefit. Apply OCP when variation is expected, not by default.
- Not modifying when you should: Continuing to hack around poorly designed code with more extensions when the real solution is refactoring the original design. Sometimes the best path is to modify the base design to make it truly extensible.
Check your understanding
Answer these without looking back at the article.
- What is the difference between modifying and extending in OCP?
- When is it acceptable to violate OCP?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.