DEV Community: Kent Phung

A CEO Said AI Replaced Developers. Then an Entire Engineering Community Opened DevTools.

Kent Phung — Wed, 22 Jul 2026 02:36:51 +0000

A story about AI, software engineering, and the difference between shipping code and shipping production systems.

A few days ago, a post from a Vietnamese CEO sent shockwaves through the local tech community.

His claim was bold.

"I pay around $20/month for Claude. It replaced developers for our internal software."

He argued that small and medium businesses no longer needed software developers, expensive SaaS subscriptions, or months of development.

Instead, they could simply describe what they wanted in natural language, and AI would build it.

The post spread rapidly across social media.

Thousands of people agreed.

Some celebrated it as the future of software development.

Others saw it as the beginning of the end for software engineers.

Everyone seemed to have an opinion.

Then, a few days later, something interesting happened.

A handful of engineers managed to find the application behind the viral post.

Out of curiosity, they did what engineers naturally do.

They opened the website.

They pressed F12.

They opened DevTools.

At first, nobody was trying to prove anyone wrong. They simply wanted to understand how it had been built.

Then the first screenshot appeared.

"Wait... why is this exposed in the frontend?"

A few minutes later, another one.

"This credential shouldn't be here."

Then another.

"Is the admin page actually protected?"

More engineers joined in.

Some inspected the JavaScript bundle.

Others monitored the network requests.

Some traced the API calls.

Within hours, screenshots, code snippets, and technical analyses started spreading across engineering groups in Vietnam.

One finding became five.

Five became twenty.

The conversation was no longer about whether AI could generate code.

It had evolved into a much more interesting question.

What's the difference between software that works and software that's ready for production?

First Impression

To be fair, the application looked surprisingly good.

The UI was clean.

Authentication existed.

Users could log in.

Data could be created and updated.

If someone had shown me only the demo video, I probably would've said:

"Wow. AI is getting incredibly good."

And honestly, I still believe that.

Because what happened next wasn't evidence that AI is bad.

It was evidence that software engineering is much bigger than writing code.

The First Five Minutes

The first thing experienced engineers inspect usually isn't the UI.

It's what the browser already knows.

Within minutes, several issues became obvious.

Sensitive configuration values were exposed directly in the frontend.

Credentials that should never live inside client-side code were accessible.

Administrative functionality wasn't actually protected by authorization.

In one case, it was simply hidden from users using CSS.

The browser wasn't supposed to display it.

But nothing stopped someone from navigating there directly.

Some API endpoints trusted the frontend far more than they should.

Several security checks that normally belong on the server appeared to be missing.

In several places, the application assumed users would behave honestly.

Software rarely gets attacked by honest users.

The most interesting part?

None of these findings required sophisticated hacking techniques.

Just a browser.

A few minutes.

And DevTools.

None of These Were AI Bugs

This is where I think many discussions go wrong.

People immediately say:

"See? AI writes terrible code."

I don't think that's true.

Claude didn't randomly decide to expose secrets.

It didn't intentionally replace authorization with CSS.

It didn't wake up one morning and think:

"Today I'm going to ignore security best practices."

It simply optimized for the task it was given.

If the prompt was:

"Build me an admin dashboard."

Then it built an admin dashboard.

Not a secure production system.

Those are two very different requests.

AI did exactly what it was asked to do.

The real problem wasn't AI.

The real problem was assuming that generating code is the same as engineering software.

It isn't.

The Demo Was Successful. The Engineering Wasn't Finished.

This is something our industry has struggled to explain for years.

Many people think software engineering is writing code.

It isn't.

Writing code is only one small part of the job.

Real engineering happens in the invisible layers.

The things users never notice.

Things like:

Authentication
Authorization
Secret management
Rate limiting
Audit logging
Monitoring
Backup strategies
Disaster recovery
Database migrations
Infrastructure
Threat modeling
Performance under load
Compliance
Security reviews

None of these appear in a product demo.

None of these make a startup launch video look cooler.

Yet these are the things that determine whether software survives in production.

AI Has Changed the Cost Curve

This is actually the exciting part.

Five years ago, building an MVP required a team.

Today?

One founder with AI can build something surprisingly impressive over a weekend.

That's incredible.

And honestly, I love it.

More people can validate ideas.

More startups can experiment.

More businesses can automate repetitive work.

AI has dramatically lowered the cost of creating software.

That is unquestionably a good thing.

But lowering the cost of creating software doesn't eliminate the need for engineering.

It simply changes where engineering creates value.

The Job Was Never Just Writing Code

This is probably the biggest misconception I see online.

People assume developers are paid to type.

They're not.

We're paid to reduce uncertainty.

We're paid to reduce risk.

Anyone can generate code.

Experience helps answer questions like:

What happens if someone bypasses the frontend?
Can users access another customer's data?
What if this service goes offline?
How do we rotate secrets without downtime?
Will this architecture still work with one million users?
How do we recover after a failed deployment?
What telemetry do we need when production breaks at 2 AM?

These questions rarely appear in prompts.

But they appear every single day in production.

Vibe Coding Isn't the Enemy

In fact, I use AI every day.

Claude
GPT
Gemini
Cursor
GitHub Copilot

They've made me dramatically faster.

AI writes boilerplate.

AI explains unfamiliar code.

AI generates tests.

AI reviews pull requests.

AI helps me prototype ideas in hours instead of days.

It's one of the best productivity tools I've ever used.

But I don't confuse acceleration with expertise.

Giving a Formula 1 car to someone who just got a driver's license doesn't create a Formula 1 driver.

It creates a faster beginner.

AI works the same way.

What Actually Happened Here?

Ironically, this story wasn't about a CEO.

It wasn't about Claude.

It wasn't even about security vulnerabilities.

It exposed something much deeper.

For years, many people—including our own industry—mistakenly equated software engineering with writing code.

AI shattered that illusion.

Writing code is becoming cheaper every month.

Engineering judgment isn't.

If anything, AI has made it even more valuable.

Because now anyone can generate thousands of lines of code.

The difficult part is knowing whether those thousands of lines should ever reach production.

My Take

I don't think AI is replacing software engineers.

I think AI is replacing the part of software engineering that we mistakenly believed was the job.

Typing code.

The real work has always been:

Understanding systems.
Managing complexity.
Designing for failure.
Protecting users.
Making good engineering decisions.

Ironically, AI is making those skills more valuable than ever.

Because when anyone can generate code...

The hardest part is no longer writing software.

It's knowing whether that software deserves to be deployed.

Final Thoughts

The viral post wasn't wrong about one thing.

AI has fundamentally changed software development.

It has lowered barriers.

It has empowered founders.

It has made individual developers dramatically more productive.

That's worth celebrating.

But the engineering community's response reminded us of something equally important.

There's a huge difference between software that impresses in a demo and software that survives in production.

One proves an idea.

The other earns trust.

And trust has always been the hardest thing to engineer.

Perhaps the biggest lesson from this story isn't that AI will or won't replace developers.

It's that AI has finally forced us to answer a question our industry has been avoiding for years:

What do software engineers actually do?

And maybe, for the first time, we now have a better answer than simply saying:

"We write code."

What do you think?

Has AI changed what it means to be a software engineer?

Or has it simply revealed what software engineering has always been about?

Why Were Our AI Interviews Getting Easier?

Kent Phung — Tue, 21 Jul 2026 07:35:14 +0000

The strange thing wasn't that more candidates were passing.

The strange thing was that nobody thought it was strange.

Six months after we launched our AI interview system, everyone was happy.

Recruiters were happy.

Hiring managers were happy.

Candidates were happy.

Even the CTO was happy.

The numbers looked fantastic.

Candidate pass rate: up 23%
Interview completion rate: up 31%
Candidate satisfaction: up 18%

Every dashboard was green.

Every weekly report looked better than the week before.

The AI interviewer seemed to be working exactly as intended.

Then someone asked an uncomfortable question.

If we're hiring better people, why aren't our teams getting stronger?

Nobody had a good answer.

The Pattern

The question came from a senior engineering manager.

Not from HR.

Not from leadership.

Not from the AI team.

He had reviewed the performance evaluations of engineers hired during the previous two quarters.

The data wasn't catastrophic.

But it wasn't improving either.

New hires were passing interviews more often.

Yet their first six months looked almost identical to previous cohorts.

The hiring funnel was getting easier.

The outcome wasn't getting better.

At first glance, it looked like normal variation.

Then we graphed the numbers.

The pass rate wasn't just increasing.

It was increasing steadily.

Month after month.

Almost like someone was turning a dial.

The Obvious Suspects

The first explanation was ChatGPT.

Maybe candidates had simply become better at using AI tools.

We checked.

No correlation.

The increase affected coding questions, system design questions, and behavioral questions equally.

That was odd.

Generative AI usually improves some categories more than others.

Not everything at once.

The second explanation was question leakage.

Maybe interview questions had spread online.

We rotated the question bank.

Nothing changed.

Pass rates kept rising.

The third explanation was model drift.

Perhaps the scoring model had gradually become more lenient.

The model version hadn't changed in months.

No retraining.

No parameter updates.

Nothing.

The system wasn't becoming easier because of the model.

Something else was moving.

Following the Scores

We stopped looking at candidates.

We started looking at interviewers.

Not human interviewers.

Human reviewers.

Our AI system generated recommendations.

Humans provided feedback.

Those feedback signals were later used to calibrate future scoring.

The design seemed reasonable.

The AI wasn't making final decisions.

Humans still approved or rejected candidates.

The system simply learned from those outcomes.

At least that was the theory.

One recruiter stood out.

Not because she reviewed more candidates.

Not because she hired more candidates.

Because her feedback disagreed with everyone else.

Consistently.

Most recruiters approved around 55–65% of AI recommendations.

She approved nearly 90%.

Every month.

Every quarter.

Every role.

Engineering.

Product.

Data.

Didn't matter.

Her approval rate barely moved.

At first we assumed she was simply optimistic.

Then we discovered something else.

The AI loved candidates she loved.

Far more than statistics would predict.

The Loop

The scoring model wasn't retraining itself directly.

That would have been easy to find.

Instead, every month we recalibrated scoring thresholds using historical hiring outcomes.

The logic seemed harmless.

If recruiters consistently approved certain profiles, the system adjusted future recommendations accordingly.

A feedback mechanism.

Designed to align AI behavior with human decisions.

The problem was scale.

One recruiter reviewed nearly three times as many candidates as everyone else.

Not because she was more senior.

Because she worked across multiple departments.

Over time her decisions became disproportionately represented in the calibration data.

Nobody noticed.

The dashboards tracked model accuracy.

They tracked candidate satisfaction.

They tracked hiring speed.

Nobody tracked influence concentration.

The AI wasn't learning from the company.

The AI was slowly learning from one person.

The Experiment

We replayed six months of interview data.

Then removed her feedback entirely.

The results surprised everyone.

The pass rate curve flattened almost immediately.

Several recommendation patterns disappeared.

The model's definition of a "strong candidate" shifted.

Not dramatically.

Just enough.

Enough to explain nearly all of the growth we had observed.

The system hadn't become smarter.

It had become more aligned with one recruiter's preferences.

And here's the uncomfortable part.

She wasn't wrong.

Many of her hires performed perfectly well.

Some became top performers.

The issue wasn't quality.

The issue was representation.

One person's judgment had become company policy.

Nobody voted on it.

Nobody approved it.

Nobody even knew it was happening.

The Hardest Bug to Explain

When we presented the findings, nobody argued with the data.

The graphs were clear.

The mechanism was clear.

The feedback loop was clear.

But one executive asked a question that stayed with me.

If her judgment was good, why is this a problem?

The room went quiet.

Because technically, it wasn't a bug.

The system worked exactly as designed.

Humans provided feedback.

The AI learned from feedback.

The AI became better at predicting future feedback.

Mission accomplished.

The problem was that we had confused consistency with objectivity.

The AI wasn't discovering what made a great engineer.

It was discovering what made one recruiter say yes.

Those are not the same thing.

What We Changed

We didn't remove human feedback.

That would have been the wrong lesson.

Instead we started measuring something we had never measured before.

Influence.

Not accuracy.

Not acceptance rate.

Influence.

Who shapes the training signal?

How concentrated is that influence?

How much of the system's future behavior can be traced back to a single source?

Those metrics never appeared on executive dashboards before.

Now they do.

The Real Lesson

The most dangerous AI failures rarely look like failures.

No outage.

No incident.

No security breach.

No alarming stack trace.

Everything was green.

Every KPI was improving.

Every report suggested success.

That's what made this one hard to see.

The system wasn't broken.

The system was becoming more confident in a perspective that nobody realized it had inherited.

The interviews weren't getting easier because candidates were improving.

They weren't getting easier because the model was drifting.

They weren't getting easier because somebody manipulated the system.

They were getting easier because one person's idea of talent had quietly become the AI's idea of talent.

And nobody noticed until the numbers looked too good to question.

SOLID and OOP: Designing Software That Survives Change

Kent Phung — Sun, 19 Jul 2026 17:13:27 +0000

Introduction
A Quick Recap of OOP
Why OOP Alone Is Not Enough
What is SOLID?
1. Single Responsibility Principle (SRP)
2. OpenClosed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)
Composition Over Inheritance
Common Misconceptions About SOLID
When Not to Apply SOLID
SOLID in a Real E-Commerce System
Conclusion

Introduction

Imagine you're building an application using Object-Oriented Programming (OOP).

At first, everything seems great:

The code is clean.
Features work correctly.
Development moves quickly.

Then new requirements arrive.

Suddenly:

Fixing one bug breaks another feature.
A single class handles business logic, database access, and email notifications.
Adding a new feature requires modifying multiple existing classes.
Testing becomes increasingly difficult.

If this sounds familiar, you've encountered one of the biggest challenges in software development:

Managing change.

This is exactly the problem SOLID was designed to address.

A Quick Recap of OOP

Object-Oriented Programming is built on four fundamental concepts.

Encapsulation: Hide internal state and expose behavior through controlled interfaces.
Abstraction: Expose only what is necessary while hiding implementation details.
Inheritance: Reuse behavior through parent-child relationships.
Polymorphism: Allow different objects to respond to the same message in different ways.

Why OOP Alone Is Not Enough

OOP provides powerful tools.

However, tools alone do not guarantee good design.

Poorly designed OOP systems often suffer from:

God Classes
Tight Coupling
Fragile Inheritance Hierarchies
Difficult Testing
Low Maintainability
Poor Extensibility

SOLID provides guidelines for using OOP effectively.

What is SOLID?

SOLID is a collection of five design principles popularized by Robert C. Martin (Uncle Bob).

S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

The goal is not perfect design.

The goal is software that remains easy to evolve over time.

1. Single Responsibility Principle (SRP)

A class should have one and only one reason to change.

Relationship to OOP

SRP complements Encapsulation by encouraging related behaviors to stay together while separating unrelated concerns.

It is also closely related to:

Cohesion
Separation of Concerns

A highly cohesive class typically has a single responsibility.

Common Misconception

A responsibility is not a method.

This is perfectly acceptable:

class UserValidator {

    public boolean validateEmail(String email) {}
    public boolean validatePhone(String phone) {}
    public boolean validateName(String name) {}
}

All methods belong to the same responsibility:

Validation

SRP Violation

class User {

    public void validate() {}
    public void saveToDatabase() {}
    public void sendWelcomeEmail() {}
}

This class has multiple reasons to change.

Benefits

Higher cohesion
Easier maintenance
Better testing
Reduced coupling

2. Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

Relationship to OOP

OCP relies heavily on:

Abstraction
Polymorphism

OCP Violation

class PaymentProcessor {

    public void process(String type) {

        if(type.equals("credit")) {

        } else if(type.equals("paypal")) {

        }
    }
}

Every new payment method requires modifying existing code.

Better Design

interface PaymentMethod {
    void process();
}

class CreditCardPayment implements PaymentMethod {
    public void process() {}
}

class PayPalPayment implements PaymentMethod {
    public void process() {}
}

OCP Is Not About Interfaces

Many developers think:

OCP = Create an Interface

Not necessarily.

Interfaces are only one implementation technique.

Other approaches include:

Strategy Pattern
Plugin Architecture
Event-Driven Systems
Dependency Injection
Configuration-Based Extensions

The real goal is:

Extend behavior without modifying stable code.

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types.

Relationship to OOP

LSP protects the correct use of:

Inheritance
Polymorphism

Example

interface Bird {
    void eat();
    void fly();
}

class Sparrow implements Bird {
    public void eat() {}
    public void fly() {}
}

class Ostrich implements Bird {

    public void eat() {}

    public void fly() {
        throw new UnsupportedOperationException();
    }
}

The abstraction promises that all birds can fly.

Ostrich breaks that promise.

Better Design

interface Bird {
    void eat();
}

interface FlyingBird extends Bird {
    void fly();
}

ISP vs LSP

Although often discussed together, they solve different problems.

Principle	Focus
ISP	Interface Design
LSP	Substitutability

LSP focuses on behavioral compatibility between abstractions and implementations.

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

ISP Violation

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {

    public void work() {}

    public void eat() {
        throw new UnsupportedOperationException();
    }
}

The interface is too broad.

Better Design

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

Benefits

Smaller contracts
Lower coupling
Easier maintenance

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

DIP Violation

class NotificationService {

    private EmailSender sender = new EmailSender();
}

Business logic depends directly on implementation details.

Better Design

interface MessageSender {
    void send(String message);
}

class EmailSender implements MessageSender {}

class NotificationService {

    private MessageSender sender;

    public NotificationService(MessageSender sender) {
        this.sender = sender;
    }
}

DIP vs Dependency Injection

A common misconception is:

DIP and DI are the same thing.

They are not.

DIP is a design principle.

DI is a technique used to implement that principle.

DIP answers:

What should depend on what?

DI answers:

How are dependencies provided?

The true goal of DIP is to ensure that business policies do not depend on implementation details.

Composition Over Inheritance

A principle commonly associated with SOLID is:

Favor Composition Over Inheritance

Example

interface NotificationSender {
    void send(String message);
}

class EmailSender implements NotificationSender {}

class SmsSender implements NotificationSender {}

class NotificationService {

    private final NotificationSender sender;

    public NotificationService(NotificationSender sender) {
        this.sender = sender;
    }
}

Notice that NotificationService does not inherit from EmailSender or SmsSender.

Instead, it composes behavior through abstraction.

Benefits:

More flexibility
Better testability
Lower coupling
Stronger support for OCP and DIP

Common Misconceptions About SOLID

Misconception #1

"Every class must have one method."

False.

SRP is about responsibilities, not method count.

Misconception #2

"OCP means creating interfaces."

False.

Interfaces are only one possible implementation.

Misconception #3

"DIP equals Dependency Injection."

False.

DI is a technique.

DIP is the principle.

Misconception #4

"SOLID should always be applied everywhere."

False.

Over-engineering is a real problem.

When Not to Apply SOLID

Not every project needs enterprise-level architecture.

For small applications:

interface UserValidator
class UserValidatorImpl

may add unnecessary complexity.

Apply SOLID when it solves a real problem.

Avoid applying it purely for theoretical purity.

SOLID in a Real E-Commerce System

SRP

Separate:

Order Processing
Persistence
Notification

OCP

Add new payment methods without modifying existing services.

LSP

Allow specialized order types to safely replace base order types.

ISP

Create focused contracts:

Payable
Refundable
Shippable

DIP

Depend on abstractions rather than specific database implementations.

Conclusion

At its core, SOLID is about managing change.

As software evolves, requirements change, business rules shift, and new features emerge.

Poor design makes these changes expensive and risky.

Each SOLID principle addresses a different source of rigidity:

SRP reduces unrelated changes.
OCP minimizes modifications to stable code.
LSP protects substitutability.
ISP avoids unnecessary dependencies.
DIP separates business rules from implementation details.

Together, these principles help developers build systems that can evolve without becoming increasingly difficult to maintain.

The goal is not to eliminate change.

The goal is to make change less expensive.

OOP Beyond the Four Pillars: State, Behavior, and Invariants

Kent Phung — Thu, 16 Jul 2026 11:04:06 +0000

Introduction
1. From Procedural to Object-Oriented
2. What Problem Does OOP Actually Solve?
3. Encapsulation — Access Control, Not Lifecycle Management
4. Inheritance — A Tool for Substitutability, Not a Default Fix for Duplication
5. Polymorphism — The Core Is Subtype Polymorphism, Not Overloading
6. Abstraction — Much Broader Than an Interface
7. Behavior-State Binding and Invariants
8. The Cost of OOP
OOP Is About Responsibility, Not Classes
A Note on Rich vs. Anemic Models
Summary

Introduction

When object-oriented programming (OOP) comes up, most people immediately list: Encapsulation, Inheritance, Polymorphism, Abstraction. But reciting four names doesn't mean understanding the substance — and worse, a lot of popular material explains these four properties in ways that are conceptually misleading.

Code examples below are written in Java, purely as notation — the ideas are the point, not the language.

1. From Procedural to Object-Oriented

Procedural: data and behavior live apart

public class Bank {
    static double balance = 1000; // Global/static state

    static void withdraw(double amount) {
        if (amount > 0 && amount <= balance) {
            balance -= amount;
        }
    }
}

balance is a static variable — any part of the program can read or write it directly, with no guarantee it's ever checked, so the data can end up in an invalid state at any time.

OOP: data bound to the behavior that protects it

(examples below use java.math.BigDecimal — the standard choice for money in Java, since double accumulates rounding error that a real invariant check can't tolerate)

public class BankAccount {
    private BigDecimal balance;

    public BankAccount(BigDecimal initial) {
        if (initial.signum() < 0) {
            throw new IllegalArgumentException("Initial balance cannot be negative");
        }
        this.balance = initial;
    }

    public boolean withdraw(BigDecimal amount) {
        if (amount.signum() > 0 && amount.compareTo(balance) <= 0) {
            balance = balance.subtract(amount);
            return true;
        }
        return false;
    }

    public BigDecimal getBalance() {
        return balance;
    }
}

The point is not "hiding balance." The point is that BankAccount exists to guarantee one rule always holds — balance >= 0 — no matter who calls what, in what order. An object isn't a box that stores data. One of the most important roles of an object is protecting invariants.

This is the starting point the rest of the article builds on.

2. What Problem Does OOP Actually Solve?

Problem in Procedural Code	OOP Mechanism
State can be mutated arbitrarily, with no guardrails	Encapsulation
Logic duplicated across variants of the same concept	Composition / Inheritance (conditionally)
Calling code has to know the concrete type it's handling	Polymorphism
System complexity makes it hard to separate levels of detail	Abstraction

Inheritance is no longer the default answer to "code duplication" — the reason follows in section 4.

3. Encapsulation — Access Control, Not Lifecycle Management

The correct definition

Encapsulation means controlling access to state and guaranteeing an invariant holds, by only allowing state changes through a controlled set of behaviors (methods).

Encapsulation is not the same thing as lifecycle management

A common conflation in OOP teaching is treating Encapsulation as if it also covers managing an object's memory or resource lifetime. It doesn't — they're different responsibilities that some languages happen to bind to the same syntax. Encapsulation is about who can touch state and under what conditions; lifecycle management is about how long a resource is held and when it gets released. An object can have one without the other: most objects, like BankAccount above, never own an external resource at all — private fields and validated methods are the whole story, no lifecycle concern in sight.

Lifecycle management only becomes relevant for the minority of objects holding something outside the object itself — a file handle, a socket, a database connection:

public class FileLogger implements AutoCloseable {
    private final BufferedWriter writer;

    public FileLogger(BufferedWriter writer) {
        this.writer = writer;
    }

    @Override
    public void close() throws IOException {
        writer.close(); // resource cleanup — nothing to do with access control
    }
}

AutoCloseable/close() exist purely to release the resource; they say nothing about who can read or write the object's state. Notice this is a separate mechanism from private/getters/setters entirely — a good illustration that Encapsulation and lifecycle management are independent concerns, not two faces of the same thing.

Bottom line: Encapsulation is a universal OOP concept that applies to every object. Lifecycle/resource management is a narrower, separate concern that only shows up when an object actually owns an external resource.

4. Inheritance — A Tool for Substitutability, Not a Default Fix for Duplication

Overriding relies on dynamic dispatch

Overriding only means something if the call is resolved by the object's actual type at runtime, not by the variable's declared type at compile time. That's what makes this work:

public class Animal {
    public void speak() {
        System.out.println("Animal sound");
    }
}

public class Dog extends Animal {
    @Override
    public void speak() {
        System.out.println("Woof!");
    }
}

Animal a = new Dog();
a.speak(); // Prints "Woof!" — resolved by the actual object, not the declared type

@Override here isn't what makes overriding happen — it's just an annotation that lets the compiler flag an error if you think you're overriding but actually got the signature wrong (e.g., a typo'd method name). It's a safety net for catching mistakes, not the mechanism itself.

Inheritance is not the default tool for "reusing logic"

The common guideline in modern design:

Favor Composition over Inheritance

The classic headache:

public class User {}
public class AdminUser extends User {}
public class SuperAdminUser extends AdminUser {}

Say AdminUser can do everything a regular user can, plus manage other users. SuperAdminUser adds billing access on top. That much fits a linear hierarchy fine. The trouble starts the moment AdminUser also needs a capability that lives on a completely different, unrelated branch — say, the same view-only, read-restricted mode that a hypothetical ReadOnlyUser has. There's no clean way to "borrow" that behavior sideways: AdminUser can't extend two classes, and forcing ReadOnlyUser into the same chain just to share one capability distorts the whole hierarchy for everyone else using it.

Composition sidesteps this entirely, because capabilities become objects you attach rather than branches you inherit from:

public class User {
    private final Permissions permissions; // just a set of granted actions

    public User(Permissions permissions) {
        this.permissions = permissions;
    }

    public boolean can(Action action) {
        return permissions.allows(action);
    }
}

// Any combination of capabilities can be composed freely — no hierarchy to fight:
User admin = new User(Permissions.of(Action.MANAGE_USERS, Action.VIEW_ONLY));
User superAdmin = new User(Permissions.of(Action.MANAGE_USERS, Action.BILLING, Action.VIEW_ONLY));

admin and superAdmin aren't different classes anymore — they're the same User class configured with a different Permissions object. Adding "view-only" to AdminUser is no longer a hierarchy problem; it's just handing it a different set of permissions at construction time.

Inheritance is only safe when the Liskov Substitution Principle holds

The "is-a" relationship by itself isn't the real test — plenty of things sound like "is-a" in English but break down in code. The actual condition is the Liskov Substitution Principle (LSP): anywhere the base class is used, substituting the subclass must work correctly without the caller needing to know it's a subclass. LSP is the reason Inheritance is trustworthy at all when it is; without it, "is-a" is just a feeling, not a guarantee.

Dog extends Animal holds up under this test — a Dog behaves as an Animal everywhere an Animal is expected. Inheriting just to "borrow a few existing methods," without that substitutability guarantee, is a signal to switch to composition instead.

5. Polymorphism — The Core Is Subtype Polymorphism, Not Overloading

Overloading is ad-hoc polymorphism — useful, but not the core

public class MathUtil {
    public int add(int a, int b) { return a + b; }
    public double add(double a, double b) { return a + b; }
}

This is resolved at compile time and has nothing to do with dynamic dispatch — it's just syntactic convenience.

The real power: subtype polymorphism

public interface Vehicle {
    void move();
}

public class Car implements Vehicle {
    @Override
    public void move() { System.out.println("Car moves"); }
}

public class Bike implements Vehicle {
    @Override
    public void move() { System.out.println("Bike moves"); }
}

public class Fleet {
    public void moveAll(List<Vehicle> vehicles) {
        for (Vehicle v : vehicles) {
            v.move(); // No need to know whether it's a Car or a Bike
        }
    }
}

This is the essence: the same call site (v.move()) dispatches to different behavior at runtime, based on the object's concrete type — Fleet needs no changes when a Truck or Boat is added.

Polymorphism lets code handle a set of different types through the same abstraction, without needing to know — or care — what the concrete type behind it is.

6. Abstraction — Much Broader Than an Interface

Interfaces and abstract classes are tools, not Abstraction itself

public interface Shape {
    double area();
}

public class Circle implements Shape {
    private final double radius;

    public Circle(double radius) { this.radius = radius; }

    @Override
    public double area() {
        return Math.PI * radius * radius;
    }
}

This example is correct but incomplete — it only illustrates one specific form called interface abstraction. A pure contract with no state (interface) and a partial implementation that can hold state (abstract class) are two different tools for achieving Abstraction — but neither one is Abstraction itself.

What Abstraction actually is

public class UserRepository {
    public void save(User user) {
        // The caller doesn't need to know:
        // - SQL or NoSQL
        // - how transactions are opened/closed
        // - how the connection pool is configured
    }
}

repository.save(user) is a complete abstraction even without any interface — as long as the caller doesn't need the internal details. Abstraction lives in the level of detail exposed through a function's name and parameters, not in whether interface/abstract is used.

In short: interface/abstract class are tools for achieving Abstraction, especially useful when multiple interchangeable implementations are needed. But Abstraction, as a design principle, exists at every layer of code — including a plain private method.

7. Behavior-State Binding and Invariants

public class BankAccount {
    private BigDecimal balance;

    public BankAccount(BigDecimal initialBalance) {
        if (initialBalance.signum() < 0) {
            throw new IllegalArgumentException("Initial balance cannot be negative");
        }
        this.balance = initialBalance;
    }

    public boolean withdraw(BigDecimal amount) {
        if (amount.signum() > 0 && amount.compareTo(balance) <= 0) {
            balance = balance.subtract(amount);
            return true;
        }
        return false;
    }

    public BigDecimal getBalance() {
        return balance;
    }
}

The important question isn't "what does this class store?" It's:

What rule does this class protect, that must always hold no matter the sequence of operations?

For BankAccount, that rule is balance >= 0 — enforced not just in withdraw, but in the constructor too, since an invariant that only holds after the first call isn't really an invariant. The entire design — private, the condition checks — exists solely to serve that one rule.

A natural follow-up question: does getBalance() returning the raw value undercut any of this? Not inherently — exposing read-only state isn't a violation by itself. What matters is where decisions based on that state get made. getBalance() lets a caller look; withdraw() is still the only way to change anything, and it's still the one place enforcing the rule. Exposing a value for reading and protecting the rules that govern changing it are two separate questions.

Protecting invariants is one of the most important responsibilities many domain objects have. In practice, this is why OOP often emphasizes keeping behavior close to the state it governs.

A related concept is identity.

Two objects may contain identical state and behavior while still represent different entities:

Customer alice1 = new Customer(1, "Alice");
Customer alice2 = new Customer(2, "Alice");

For that reason, many classic OOP definitions describe an object as:

Identity + State + Behavior

This article focuses primarily on responsibility and invariant protection, but identity remains an important part of object-oriented thinking.

Not All Invariants Belong to a Single Object

The examples in this article focus on invariants protected by a single object.

Real systems often contain rules that span multiple objects:

An order cannot be shipped unless it has been paid.
Inventory cannot become negative.
A bank transfer must debit one account and credit another.

Protecting such rules often requires coordination beyond a single object and is one of the motivations behind concepts such as Aggregates in Domain-Driven Design. An Aggregate defines a consistency boundary within which invariants are guaranteed to hold.

8. The Cost of OOP

Deep inheritance hierarchies: the more extends layers, the harder to test and refactor.
Anemic Domain Model: extremely common in Spring-style Java codebases. A class ends up as nothing but fields and getters/setters:

  public class User {
      private String email;

      public String getEmail() { return email; }
      public void setEmail(String email) { this.email = email; } // no validation, no rule
  }

Anywhere that needs to change an email now has to duplicate the validation logic itself (UserService, a controller, a batch job — whoever gets there first), because User enforces nothing. Compare that to keeping the rule where the state lives:

  public class User {
      private String email;

      public void changeEmail(String newEmail) {
          if (!newEmail.contains("@")) {
              throw new IllegalArgumentException("Invalid email");
          }
          this.email = newEmail;
      }
  }

setEmail just stores whatever it's given — the object protects no invariant, so it isn't really acting as an object in the OOP sense, just a data bag with a class-shaped label. changeEmail puts the rule back where it belongs.

Overusing Inheritance for code reuse instead of modeling a genuine "is-a" relationship.
Interface explosion — creating an interface for everything "just in case" before there's an actual need (a violation of YAGNI) — a fairly common habit in the Java/Spring ecosystem.

A counterbalancing principle worth knowing: Tell, Don't Ask — instead of if (account.getBalance().compareTo(amount) >= 0) { ... } followed by external handling, call account.withdraw(amount) so the decision logic stays close to the data it governs.

OOP Is About Responsibility, Not Classes

A useful test for whether a codebase is actually object-oriented, or just uses class as a file-organization convention: pick a business rule and ask which object owns it.

User
UserService
UserValidator
UserMapper
UserHelper

Five classes, one entity. If the email-format rule from the example above lives in UserValidator, the discount calculation lives in UserService, and User itself is just the anemic getter/setter bag — then no single object owns any rule. The rules float between service and helper classes that operate on data rather than objects that are responsible for their own data. That's a procedural program wearing class syntax, not OOP.

The fix isn't to delete UserService — coordinating multiple objects across a use case is a legitimate job for a service layer. The fix is narrower: the rule that only concerns User's own state (is this email valid, can this balance go negative) belongs on User, not scattered across whichever class happened to need it first. Everything in sections 3 and 7 — encapsulation as invariant protection, behavior bound to state — comes down to this one habit: before writing a rule, ask which object it actually belongs to.

A Note on Rich vs. Anemic Models

The examples in this article intentionally focus on objects that own and enforce their own invariants.

That does not mean every architecture must place every business rule inside an entity.

The important question is not where a piece of code physically lives, but which part of the system is responsible for maintaining correctness.

Responsibility matters more than placement.

CRUD applications, reporting systems, data pipelines,
and some functional architectures intentionally separate
data from behavior.

Anemic models become a problem only when invariants
and business rules end up scattered with no clear owner.

Summary

Property	Core Essence	Not to Be Confused With
Encapsulation	Access control + invariant protection	Lifecycle/resource management (`close()`, GC)
Inheritance	Subtype substitutability (LSP)	The default tool for code reuse
Polymorphism	Runtime dispatch through a shared abstraction	Overloading (ad-hoc polymorphism)
Abstraction	Hiding detail at the right level	`interface`/`abstract class` (just a tool)

None of this is really about Java — swap in any language with dynamic dispatch and a garbage collector and the same points hold.
The four properties above are useful vocabulary, but they are not the essence of OOP.
The deeper idea behind object-oriented programming is responsibility.
An object owns identity and state, exposes behavior, and protects the invariants that define its correctness. Some invariants belong to individual objects, while others belong to larger parts of the system. The role of design is to place each responsibility where it can be protected most reliably.
Encapsulation, Inheritance, Polymorphism, and Abstraction are valuable tools, but they matter only insofar as they help responsibilities stay in the right place and correctness remain protected.
To go deeper: SOLID principles, Domain-Driven Design (DDD), Dependency Inversion, and Rich Domain Model vs. Anemic Domain Model.

DEV Community: Kent Phung

A CEO Said AI Replaced Developers. Then an Entire Engineering Community Opened DevTools.

First Impression

The First Five Minutes

None of These Were AI Bugs

The Demo Was Successful. The Engineering Wasn't Finished.

AI Has Changed the Cost Curve

The Job Was Never Just Writing Code

Vibe Coding Isn't the Enemy

What Actually Happened Here?

My Take

Final Thoughts

Why Were Our AI Interviews Getting Easier?

The Pattern

The Obvious Suspects

Following the Scores

The Loop

The Experiment

The Hardest Bug to Explain

What We Changed

The Real Lesson

SOLID and OOP: Designing Software That Survives Change

Table of Contents

Introduction

A Quick Recap of OOP

Why OOP Alone Is Not Enough

What is SOLID?

1. Single Responsibility Principle (SRP)

Relationship to OOP

Common Misconception

SRP Violation

Benefits

2. Open/Closed Principle (OCP)

Relationship to OOP

OCP Violation

Better Design

OCP Is Not About Interfaces

3. Liskov Substitution Principle (LSP)

Relationship to OOP

Example

Better Design

ISP vs LSP

4. Interface Segregation Principle (ISP)

ISP Violation

Better Design

Benefits

5. Dependency Inversion Principle (DIP)

DIP Violation

Better Design

DIP vs Dependency Injection

Composition Over Inheritance

Example

Common Misconceptions About SOLID

Misconception #1

Misconception #2

Misconception #3

Misconception #4

When Not to Apply SOLID

SOLID in a Real E-Commerce System

SRP

OCP

LSP

ISP

DIP

Conclusion

OOP Beyond the Four Pillars: State, Behavior, and Invariants

Table of Contents

Introduction

1. From Procedural to Object-Oriented

Procedural: data and behavior live apart

OOP: data bound to the behavior that protects it

2. What Problem Does OOP Actually Solve?

3. Encapsulation — Access Control, Not Lifecycle Management

The correct definition

Encapsulation is not the same thing as lifecycle management

4. Inheritance — A Tool for Substitutability, Not a Default Fix for Duplication

Overriding relies on dynamic dispatch

Inheritance is not the default tool for "reusing logic"

Inheritance is only safe when the Liskov Substitution Principle holds

5. Polymorphism — The Core Is Subtype Polymorphism, Not Overloading