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.
Top comments (0)