DEV Community: sour_grape

My Take on OOP (Part 7): Dependency Injection is No Big Deal

sour_grape — Tue, 24 Jun 2025 16:50:28 +0000

Requirements, Contracts, Messages

These are the three things I've emphasized while explaining Object-Oriented Programming.

By now, you should understand that these three aren't independent concepts; they are organically connected. This entire series of articles has just been a demonstration of their natural flow.

I've said that interfaces and polymorphism are just about "swapping parts."

But is swapping parts really that easy? There's a hidden trap. Today, I'm going to talk about that trap and how Dependency Injection (DI) is just the good old object-oriented way of fixing it.

Let's Design Based on What We've Learned

We get the theory, so let's see how it's reflected in code. I'll do exactly what we've been doing in the previous parts.

The Requirement and the Contract: "Hey, come by car."

There are two parts to this contract: you have to come to the meeting spot, and you have to come by car.

So, we design the contract as an interface, like this:

interface Car {
    void move();
}

class Friend {
    private final Car car;

    // We inject the contract that the friend must come by car.
    public Friend(Car car) {
        this.car = car;
    }

    public void goToAppointment() {
        this.car.move();
    }
}

So far, so good. We've designed this naturally. Unlike the bad example from before, we haven't hardcoded a "Red 2023 Ford Mustang GT, license plate 8XN-4Y2" directly into our design. We just naturally included a Car interface in the class, just like how we talk. This is great.

2. Now, Let's Send the Message: "You Figure It Out"

We have to send a message that says, "Just honor the contract and you figure out the rest."

But You Have to Use the Design, Right?

Okay, we've designed our object-oriented system naturally. Why did we design it? To use it, obviously. Let's implement the real-world scenario of me telling my friend to come by car.

public class Me {
    public static void main(String[] args) {
        // "I" want to get my friend to come to the appointment.
        // But... "I" have to personally create the 'car' to give to my friend.
        Car aFriendsCar = new MyFordMustang();

        // And then I create the friend who has that car.
        Friend friend = new Friend(aFriendsCar);

        // Only now can I tell my friend to come to the meeting spot.
        friend.goToAppointment();
    }
}

I said we have to send a message to our friend. Let me emphasize it again. OOP is this:

"As long as you honor the requirements and the contract, you figure out the rest."

In the previous example, we honored the requirements and the contract, and we designed the method—the messenger—well by using an interface. It seems like we should be able to send the "You figure it out" message. But there's a trap in the process of sending this message.

In the code above, for me to send a message to my friend, I have to inject the specific car information myself.

This is the same as the situation where I know my friend's car is a "Red 2023 Ford Mustang GT, license plate 8XN-4Y2."

In other words, this code is exactly the same as me saying, "Hey, come in that Red 2023 Ford Mustang GT, license plate 8XN-4Y2, that you own."

You go through all the trouble of designing a good, "you-figure-it-out" OOP system, only to ruin it all at the very last step when you actually run it. It's the worst-case scenario.

So How Do We Fix It?

What's the object-oriented way to solve a problem like this? Like I've been saying, you send a message: "You figure it out."

In the code above, the situation is messed up because when it was time to create the friend who would perform the action, I injected the specific car information. In other words, it's a situation I messed up by doing the injection myself.

So, what if I don't do the injection? What if I just send a message to "go figure out the injection yourself"?

Then we can just create a 'guy' whose only job is to do the injecting, and give him an order: "Hey, you handle the injection."

We can express it like this:

public class CarFactory {
    // This is the response to the request, "I need a car, prepare one."
    public Car createCar() {
        // Only this guy knows what the friend's car is.
        return new MyFordMustang();
    }
}

Then, I can send my message like this:

public class Me {
    public static void main(String[] args) {
        // I call the guy who knows what my friend's car is.
        CarFactory carFactory = new CarFactory();

        // I delegate all the specific details to that guy.
        // "I" no longer know if it's a 'MyFordMustang'. I just know it's a 'Car'.
        Car aFriendsCar = carFactory.createCar();

        // I don't know what kind of car it is, I just send the message to my friend: "Hey, come by car."
        Friend friend = new Friend(aFriendsCar);

        // Then my friend figures it out and comes by car.
        friend.goToAppointment();
    }
}

I solved the trap of knowing my friend's car by using the original object-oriented solution. I created a 'guy' who handles injecting the car info, and I just sent him a message to do his job.

I have perfectly implemented the "Hey, come by car" message, instead of the "Hey, come in your specific Ford Mustang" command.

Conclusion

When people explain DI, they throw around a bunch of complicated words like "Inversion of Control~~" or "reducing coupling~~"...

It's just the same old OOP trick for avoiding the trap. It's no big deal. It's just sticking to the "you figure it out" attitude to the very end.

My Take on OOP (Part 6): Forget "Polymorphism." It's Just Swapping Parts.

sour_grape — Tue, 24 Jun 2025 16:38:27 +0000

I Like Feynman

I'm a big fan of Richard Feynman. If you study physics, you usually end up reading his famous "Red Books," and from there, you get into his biographies. Feynman used to say, "If you can't explain something in simple terms, you don't understand it yourself."

That's probably why he won a Nobel Prize for explaining theories with simple diagrams.

Anyway, my point is, I don't get why people insist on explaining Object-Oriented Programming in such a ridiculously complicated way.

Benefits of an Interface

I've been emphasizing that the biggest benefit of an interface is that it lets you define and enforce a contract in code. Another great benefit is polymorphism.

I already explained this naturally when I talked about abstraction in the last part.

If you just write up the contract, you don't have to care how it's implemented. To bring back the analogy from last time:

The contract "Come by car" just means you have to show up in a car. My friend doesn't care if I take a taxi, a bus, or my own car. I just have to get there by car.

So if you flip that around, it means as long as I'm in a car, I can change my mind whenever I want, right?

I was planning to take the bus, but I'm running late, so I'll take a taxi instead. No problem. This freedom to change my mind based on my situation, to swap things out as I please—that's polymorphism.

Why Polymorphism Exists: OOP and Messages

The core of OOP, as I've said, is a strict division of labor. It's a system where everyone minds their own business and just sends messages to each other. It's a system where you just throw the contract over the wall and tell the other guy, "You figure it out." Polymorphism is the natural result of this system.

My way? Yeah, my way. As long as I honor the contract, I'll do it however I want. And if I don't like it later, I'll swap it out myself. You just get the result. That's the deal. That's the contract.

Implementing, swapping, and changing things however you want—as long as you uphold the contract and deliver the result—that's a successful division of labor, that's successful messaging, that's proper OOP.

The Benefit of Polymorphism

I'll show you exactly what this looks like in code.

// The Contract
interface Car {
    void moveTo(String destination);
}

class Person {
    // anyCar, i.e., as long as it's a car, anything goes.
    public void goToAppointment(Car anyCar) {
        anyCar.moveTo("the meeting spot");
    }
}

public class Main {
    public static void main(String[] args) {
        // "Me," who needs to get to an appointment
        Person me = new Person();

        // I can make and use whatever I want to ride.
        Car myCar = new MyFordMustang();
        Car taxi = new Taxi();
        Car bus = new Bus();

        System.out.println("--- Today's Plan ---");

        // I just have to honor the "Come by car" contract.
        // Which 'Car' I use is completely up to me.

        System.out.println("1. Maybe I'll take my own car today?");
        me.goToAppointment(myCar); // I'm taking my car.

        System.out.println("2. I should take a taxi tomorrow.");
        me.goToAppointment(taxi); // Gotta take a taxi.

        System.out.println("3. Let's take the bus the day after.");
        me.goToAppointment(bus); // Taking the bus.
    }
}

You hear a lot of talk about "flexibility" and "extensibility." Isn't this more intuitive? The contract just has to be met, so of course it's flexible and extensible.

No, let's put it more simply: The biggest advantage is that nothing breaks when I swap things out as I please.

When you want to change code later, it usually falls into two categories:

You change the requirements and the contract.
You change the implementation.

Number 1 means you just change the interface.
Number 2 means you just build a new implementation, throw out the old one, and swap in the new one.

Polymorphism is what gives you the power to do #2.

Conclusion

Polymorphism is born from the division of labor and messaging in OOP.
Polymorphism is the freedom to swap things out as you please, as long as you honor the contract.

My Take on OOP (Part 5): "Abstraction" is a Scary Word. It's Just How We Talk.

sour_grape — Tue, 24 Jun 2025 16:27:41 +0000

Abstraction??

The poster child for abstraction is mathematics. And let's be honest, mathematical abstraction is notoriously difficult. If you can actually enjoy it, you have a real talent for math.

Because it has such a bad reputation, people assume programming abstraction must be hard, too.

In a way, they're the same. But in another, they are completely different.

Programming Abstraction is Our Daily Life

Abstraction in programming is our everyday life. It's our language.

What "abstraction" means in programming is the same as how we normally talk. To be precise, it's the method for expressing the 'Contracts' I find so important.

Let's say I'm making plans with a friend. I can tell them, "Come by car tomorrow." A totally normal phrase, right? But that is programming abstraction.

The Contract is: You must arrive at the meeting place tomorrow, and you must come by car.

That's it. Those are the only two conditions. As long as I fulfill those two, the specific details of how are completely up to me. My friend doesn't care if I take a taxi, a bus, or my own car.

So what does it mean to not use abstraction in programming?

It's like your friend saying, "Tomorrow, come in your Red 2023 Ford Mustang GT, license plate 8XN-4Y2."

If you talked like that in real life, people would think you're a psycho. And the biggest problem with this "contract" is that I must come in that specific Ford Mustang.

But what if I sold it? What if it's in the shop for repairs? What if I bought a new car? What if I left my car in another city? It becomes difficult to fulfill the contract, and the truly important part—showing up to the meeting—is blocked by a trivial constraint.

This happens because your friend knows the specific details of the car you own.

"Just make sure it's a car, and you figure out the rest." That's how we normally talk.

"Turn on your laptop so we can video call." "Grab a spoon so we can eat." "Check your texts." "The car broke down, so take it to a repair shop." All of this everyday language is abstraction. It's completely natural to us.

But imagine if people said this instead:
"Turn on your M2 MacBook Air for the video call." "Grab that specific spoon from the Chinese restaurant." "Check your texts on your iPhone 14." "Your Red 2023 Ford Mustang GT, license plate 8XN-4Y2, is broken, so take it to the specific Ford dealership on 123 Main Street to get it fixed."

That's not abstraction; that's defining a contract with needless, suffocating detail. It's a contract you can't fulfill if circumstances change later. Besides, who even talks like that?

But in programming, we make this mistake all the time.

Let's translate that "psycho conversation" into code.

// The concrete implementation: a Ford Mustang GT
class FordMustangGT {
    public void driveTo(String destination) {
        System.out.println("Driving the Ford Mustang GT smoothly to " + destination + ".");
    }
}

// The requester: demands a specific 'FordMustangGT'
class Person {
    public void goToAppointment(FordMustangGT myCar) {
        // This code can only talk to a 'FordMustangGT'.
        myCar.driveTo("the meeting spot");
    }
}

// The execution code
public class Main {
    public static void main(String[] args) {
        Person person = new Person();
        FordMustangGT mustang = new FordMustangGT();
        person.goToAppointment(mustang);
    }
}

Writing code like this is often seen as perfectly natural. Isn't that weird? The very way of speaking that would get you labeled a psycho in real life is considered normal in programming.

Now let's change it to a natural, everyday conversation.

// 1. The Contract (Interface): Defines the "must be able to move" contract
interface Car {
    void moveTo(String destination);
}

// 2. The various implementations that honor the contract
class MyFordMustang implements Car {
    @Override
    public void moveTo(String destination) {
        System.out.println("Driving my Ford Mustang to " + destination + ".");
    }
}

class Taxi implements Car {
    @Override
    public void moveTo(String destination) {
        System.out.println("Calling an Uber to get to " + destination + ".");
    }
}

class Bus implements Car {
    @Override
    public void moveTo(String destination) {
        System.out.println("Taking the 143 bus to " + destination + ".");
    }
}

// 3. The requester: Depends only on the 'Car' contract
class Person {
    public void goToAppointment(Car anyCar) {
        // This code can talk to ANY object that honors the 'Car' contract.
        anyCar.moveTo("the meeting spot");
    }
}

// 4. The execution code
public class Main {
    public static void main(String[] args) {
        Person person = new Person();

        // Today, I'll use my own car.
        person.goToAppointment(new MyFordMustang());

        // Tomorrow, I'll take a taxi.
        person.goToAppointment(new Taxi());

        // The day after, I'll take the bus.
        person.goToAppointment(new Bus());
    }
}

I'll admit, writing the code this way can feel like a pain. It seems like more effort, so you're tempted to just write the specific, concrete code. But this "good" code is just a direct translation of our natural, everyday life. I think it's strange to treat the same concept so differently.

Conclusion

Abstraction is the natural language we use every day.

Next time, I'll explain the specific benefits of using abstraction like this.

My Take on OOP (Part 4): TDD Isn't a Cult, It's a Contract

sour_grape — Tue, 24 Jun 2025 16:17:45 +0000

Why I Hate TDD

You've probably heard the TDD mantra:

RED: First, write a failing test.
GREEN: Write the actual code to make the test pass.
BLUE: Refactor to remove duplication, generalize, etc.

This is why I hate TDD.

But I also love TDD.

Sounds like nonsense, right? Let me explain. I don't think the essence of TDD is this rigid formula.

If you've read the first three parts of this series, you know how critical it is to honor your requirements and contracts. We use interfaces in our software to represent these contracts. But how do we know if the contract is actually being fulfilled? Is conforming to an interface enough to satisfy our requirements?

It’s not enough.

We test to see if our implementation honors the requirements and contracts. So, isn't the ultimate goal to uphold the contract? Then doesn't it make sense to first create a test that verifies the contract?

TDD is the verification of a contract. TDD is a true test that checks if the implementation satisfies the agreement. If the tests don't pass, the implementation is a failure. Why? Because it broke the contract.

Do you see why I hate the way TDD is described? TDD is a contract verification. It's a living guarantee, a document that evolves. But the dogma tells you to intentionally write failing code?

The 'RED' step isn't about aiming for failure. It's a natural consequence. You've simply defined the 'contract to be fulfilled' (the test) first, and the implementation that satisfies it doesn't exist yet. The 'failure' isn't the goal; it's just the expected state before the contract is fulfilled. Describing this as "deliberately failing" distorts the purpose and puts the cart before the horse.

Why I Love TDD

If you've read the rest of this series, you'll understand how much I value requirements and contracts.

Whether you write the test first or after, I love TDD from the perspective that it verifies the contract. This is how I use TDD.

To make it easy to understand, here's a unit test file for a Value Object (VO) class I wrote.

class TestActorValueObject(unittest.TestCase):

    def test_create_valid_actor_all_fields(self):
        # Contract: Must be able to successfully create an ActorVO with all valid fields.
        vo = ActorVO(name="Tom Hanks", role_name="Forrest Gump", external_id="tmdb_actor_123")
        self.assertEqual(vo.name, "Tom Hanks")
        self.assertEqual(vo.role_name, "Forrest Gump")
        self.assertEqual(vo.external_id, "tmdb_actor_123")

    def test_create_valid_actor_name_only(self):
        # Contract: Must be able to successfully create an ActorVO with only the required field, name.
        vo = ActorVO(name="Song Kang-ho")
        self.assertEqual(vo.name, "Song Kang-ho")
        self.assertIsNone(vo.role_name)
        self.assertIsNone(vo.external_id)

    # ... (and so on for all other test cases) ...

    def test_create_with_empty_name_raises_value_error(self):
        # Contract: Attempting to create with an empty name must raise a ValueError.
        with self.assertRaisesRegex(ValueError, "Actor name cannot be empty."):
            ActorVO(name="")

    def test_actor_equality(self):
        # Contract: Two ActorVO objects must be equal if all their attributes are the same.
        vo1 = ActorVO(name="Same Actor", role_name="Same Role", external_id="ext1")
        vo2 = ActorVO(name="Same Actor", role_name="Same Role", external_id="ext1")
        self.assertEqual(vo1, vo2)

    def test_actor_string_representation(self):
        # Contract: The string representation of an ActorVO object must be displayed appropriately.
        vo_with_role = ActorVO(name="Ma Dong-seok", role_name="Maseokdo")
        self.assertEqual(str(vo_with_role), "Ma Dong-seok (Role: Maseokdo)")

As you can see, I explicitly state the contracts and constraints that arise from the design as comments. No matter how I implement or change ActorVO, it must honor these contracts. This test suite is the living document that guarantees it.

What if the requirements themselves change and the contract is updated? I just modify the test. And of course, I update the contract in the comment.

My Thoughts on assert

When I first started writing tests, the thing I understood the least was assert.

You create a result and then check if it matches what you expect. What's the point of that? Seems like a waste of time, right?

But as we've seen in this series, requirements and contracts are what matter.

The word assert means "to state a fact or belief confidently and forcefully." Why do we need to 'assert' something in a test? Because we have to verify that the contract is being met.

assert(my_implementation_result, what_the_contract_requires)

This assertion is, in essence: my_implementation_result == contract_satisfaction_value.

The assert statement is the most intuitive expression of the purpose of testing: verifying the contract.

Conclusion

TDD is a helper for OOP. It's the living document that verifies our requirements and contracts are being met.

My Take on OOP (Part 3): DDD is Just the Instruction Manual for OOP

sour_grape — Tue, 24 Jun 2025 16:06:44 +0000

How to Design OOP Well

I'm no expert on Domain-Driven Design (DDD), but as far as I can tell, it's just a fancy term for doing OOP well.

But what does "doing OOP well" even mean? I think it boils down to this:

You have to divide things just right.
You have to group things just right.
The groups have to send messages to each other just right.
And that messaging needs to be performant, secure, and stable.

I know you might hate that phrase, "just right." It sounds vague. But I believe that single phrase is the very essence of design.

Everything is a Trade-off

There are no silver bullets in software. No flawless solutions, no magic answers that fix everything. Every choice is a trade-off, which means you have to analyze the situation and find the most "just right" solution for the context.

I didn't make this up; this is what architects always say.

The hardest part of project design is this fundamental nature of software. Since there are no objective criteria for "just right," your choices will always be subjective.

Take OOP, for example:

You divide business logic just right, according to the requirements.
You group business logic just right, according to the requirements.
The boundaries communicate just right, according to the requirements.
You implement robust communication just right, according to the requirements.

DDD acts as the guidebook that helps you establish the criteria for 'just right'.

The Subject of DDD

Let's state it again: software is about making money. To make money, you have to satisfy your users. To satisfy your users, you have to fulfill their requirements.

Therefore, DDD starts with getting as specific as possible about the requirements through communication with the customer. And to do that, you first need smooth communication.

That's why DDD defines what's called a Ubiquitous Language.

In simple terms: developers should primarily use the language that the business experts use.

You know that one tech guy who insists on using overly technical terms and jargon for no reason? It's annoying as hell, right? It's the same feeling. You don't want to talk to people who deliberately use difficult language when it's not necessary.

That's exactly how the customer feels. They're trying to explain what they want, and the developers are mixing in programming terms. The customer can't understand a thing and just gets frustrated.

On the flip side, developers have to fully understand the context behind the customer's requirements. We call this the Domain. If you don't understand the business, you can't understand the business's terminology.

The Ubiquitous Language is the shared vocabulary that everyone—developers and customers alike—agrees to use to ensure smooth communication. It's the process of using these defined terms in your requirements docs, and even in your code, to eliminate any chance of misunderstanding.

Dividing and Grouping 'Just Right'

Once you've defined the Ubiquitous Language, you start dividing the entire business into domains of responsibility.

A popular method for this is Event Storming, but I'm not gonna explain it here. Just look it up. It's a workshop where not just developers, but customers too, get together and map things out. Sometimes you divide based on data, sometimes based on ownership. For the details, check out a book on DDD.

Once you've drawn the boundaries for the business logic, you have to group the related things inside. Of course, the trick here is also to group them "just right." Usually, you group things based on transactional consistency. And you pick one object in the bundle to be the "representative" or "gateway" for the group. This is the Aggregate and Aggregate Root.

When these groups communicate, they use this gateway as the standard. This naturally allows you to achieve the OOP goals of:

Communicating between boundaries according to requirements.
Implementing robust communication according to requirements.

Conclusion

The Ubiquitous Language solved the problem of communication, which was plagued by misunderstandings and assumptions, and clarified the essence of the requirements.
The Bounded Context gave us clear criteria—'responsibility and language'—to divide a massive business "just right."
The Aggregate provided a standard for grouping related concepts "just right" within those boundaries, based on the principle of 'data consistency.'
The Aggregate Root opened a path for these well-divided and grouped units of responsibility to communicate safely through a clear 'gateway,' without treading on each other's toes.

This is how DDD helps you design OOP well.

My Take on OOP (Part 2): Requirements and Contracts

sour_grape — Tue, 24 Jun 2025 15:54:31 +0000

Requirements are Money

Personally, I think the most important thing in software is making money.

To make money, you have to satisfy your users or customers. And to do that, you have to satisfy their requirements. Therefore, the most critical job in software is to figure out and fulfill the requirements. Period.

OOP and Requirements

Requirements and Object-Oriented Programming are two sides of the same coin. In fact, almost everything in software—OOP, TDD, DDD, and by extension, Microservices—are all just tools to help us satisfy requirements better.

If your requirements are a mess, all those fancy acronyms are useless. But on the flip side, if you get the requirements right and truly understand the "division of labor" I talked about in Part 1, it finally clicks: all these methodologies exist to serve the requirements.

Requirements and Contracts

I'm not going to talk about how to gather good requirements here. We'll also save TDD and DDD for later. For now, let's just focus on how to implement well-defined, real-world requirements in software.

In this series, I'm going to define the methods, expressions, and promises needed to satisfy a requirement as a "Contract."

A well-designed requirement defines constraints and necessary actions. For example, a smartphone display has the following requirements:

It must turn on.
Its brightness must be adjustable.

This is a requirement, a contract, a constraint. When we implement this in software, it's a non-negotiable contract we have to fulfill.

And the tool that lets us express and enforce this contract in code is the Interface.

interface Display {
    void turnOn(); // It turns on.
    void setBrightness(int level); // Its brightness can be adjusted.
}

In the example above, the display's contract can be explicitly defined in code like this. Therefore, the interface is the tool that guarantees and enforces this contract in code.

The Development Process

If you strip away the operational stuff and just focus on implementing features, the process looks like this:

Listen to the requirements through meetings with the client.
Flesh out the requirements through ongoing meetings.
Write up the contract.
Execute the project design.
Translate the contract for each part into an interface in code.
The implementation classes must then honor this interface contract to complete the work.

The project's design is critical, and using interfaces is an extension of that design process. That's why they are so important.

Back to Requirements and OOP

So, what does all this have to do with Object-Oriented Programming?

If the essence of OOP is the 'division of labor', then requirements are the very work that gets divided. They are the standard for that division.

We look at the requirements to decide what to split apart. We analyze the requirements to group related things together. This very process—of dividing and grouping the system appropriately based on requirements and assigning clear responsibilities to each part—is the object-oriented approach.

And the interface is the tool that enforces the promises (the contracts) between these divided, collaborating objects.

(Next time, we'll discuss this further.)

My Take on OOP (Part 1): It's Just a Damn Assembly Line

sour_grape — Tue, 24 Jun 2025 15:15:21 +0000

People usually learn Object-Oriented Programming by studying the history of procedural versus object-oriented paradigms.

My fundamentals are lacking, so I'm just going to interpret OOP my own way.

A Quick Rant

Here's my philosophy: Software is made by people. Purely. That means every single thing in software exists because of an intention.

Given my background, I know that even physics, which people mistake for a search for absolute truth, is full of human interpretation. Software is no different.

Therefore, to understand software is to understand the choices and intentions of the people who made it.

And don't treat the original creators like gods. Their ideas aren't made of steel. If you stop being intimidated and just try to figure out what they were thinking, you'll get it pretty quickly.

The Purpose of OOP

Why was OOP even created? To build and run programs well. But the model for getting work done efficiently was already perfected during the industrial age.

Object-Oriented Programming is the division of labor.

The era of artisans passed. With the discovery of coal and the invention of the steam engine, factory-style production through a division of labor proved to be incredibly efficient. This is self-evident.

Since I'm currently at SSAFY (Samsung Software Academy for Youth), let's use Samsung Electronics as an example.

Samsung operates through a ruthless division of labor. You have Samsung's DX (Device eXperience), DS (Device Solutions), Research, and so on. Within those, you have business units, and within those, more departments.

The point is, the entire company is organized around a strict division of labor, with each part having its own clear responsibilities. For example, when Samsung makes a smartphone, countless departments—product planning, design, development, software—collaborate to complete the final product.

You could say that OOP is just a direct software implementation of this brutally efficient model.

Therefore, to understand the principles of OOP, you first have to burn this into your brain: OOP is all about the division of labor.

Design Patterns, 'Laws' of OOP?

I refuse to memorize that stuff.

One thing I've noticed about the software field is its weird obsession with jargon and definitions. You get these interview questions like, "Explain encapsulation, polymorphism, and abstraction." Memorizing that crap doesn't seem very helpful.

If you just think from the perspective of the division of labor, these principles become dead-simple common sense.

Let's go back to the Samsung example.

If Samsung pursues peak efficiency through a strict division of labor, then messing up that division kills efficiency.

The phone's design belongs to the design department. The display is made by the display department. The company's operations are run by the management department. The other departments don't need to—and shouldn't—know their internal business. (That's Encapsulation.)

When these departments collaborate, they just send messages. The guys on the assembly line just tell the parts department, "Gimme the materials." That's it. They get the materials back as a result. (That's Messaging.)

When they send these messages, they don't need to know the implementation details of each department.

"Gimme a display." (Good).
"Gimme the display with serial number (xxs~~~), produced on this date, with these materials, from that factory..." (Bad).
(That's Abstraction.)

Think strictly in terms of dividing labor. That is Object-Oriented Programming.

Anti-Patterns

An anti-pattern is when this division of labor breaks down. Simple as that.

A classic example is the kind of problem at Samsung you see mentioned on Blind (an anonymous employee app). The business guys don't need to know the tech. The technology should be the sole responsibility of the engineers, and management should stick to its own responsibilities. When management crosses that line and meddles with technology, the division of labor has failed, and efficiency is ruined.

OOP is the exact same. The dependency issues people talk about happen when one object crosses into another's territory and gets too tangled up in its business.

The way to design OOP well is to group things appropriately and divide responsibilities appropriately. To perfect the division of labor.

Next time, I'll discuss the methods for doing this.