DEV Community

Cover image for OOP Principles For Dummies

OOP Principles For Dummies

Tamerlan on March 21, 2021

I don't have much experience but been in a couple of interviews. They seem to always ask the same cliche questions. For example: Where do you ...
Collapse
 
andreidascalu profile image
Andrei Dascalu

Although encapsulation and inheritance are quite dead and buried.

Collapse
 
tamerlan profile image
Tamerlan

what do you mean by "dead"?

Collapse
 
andreidascalu profile image
Andrei Dascalu • Edited

Well, in the case of inheritance it's been widely considered an anti pattern for years now. In a way it's "deprecated" in favor of composition (composition over inheritance). Mostly because it tightly couples your objects in a tangled hierarchy that prevents useful reusability.
In the case on encapsulation, it turns out it makes little sense. Bind data and operations? Data is inert, it doesn't have agency. It's not a logical representation of concepts that you can work with. A chair doesn't change itself. But on a practical level, mutable states are an enemy of stability and predictability in code. That's why immutability has continuously grown in popularity as a practice and is a core concept of DDD. But if immutability is preferred, why encapsulate at all? You're not changing the bound (current) instance so you might as well cleanly pass data to a pure function and receive a changed dataset. And lastly, just about any OOP language provides reflection mechanisms that can be used to break encapsulation (so it's not much of a guarantee of anything).
There's a fairly famous quote about the downsides of inheritance (and it also hints at encapsulation as well):
“… Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang

Thread Thread
 
zorqie profile image
I, Pavlov

I'm afraid in 2021 Erlang is a lot more "dead and buried" than encapsulation and inheritance. There's probably a good reason why it isn't in IEEE's top 50 programming languages, unlike Python, Java, C#, JavaScript and other gorilla-feeding jungles.

Functional programming is trendy and "beautiful" and "pure". OOP pays the bills.

Thread Thread
 
andreidascalu profile image
Andrei Dascalu

Sure, but it's OOP that advocates composition over inheritance as well as immutability nowadays. It has nothing to do with functional programming, just a note that FP can do immutability better.

Also a note: unlike Java and C# which are fundamentally OOP, Python and Javascript are true multi paradigm languages - they can do FP just as much as the next.
In development, things tend to change.

Thread Thread
 
zorqie profile image
I, Pavlov

"Advocates" is almost but not quite entirely unlike "deprecated". OOP provides different tools for different use cases and it's the developer's responsibility to use them appropriately. This is like "advocating" hammers over wrenches. Immutability is as useful as nails but there are situations where screws work better. FP has become Maslow's hammer of programming these days.

My opinion is best expressed by Steven Lowe here

I'm sure (though have no data) that FP's invasive expansion into JS and Python correlates to the number of Erlang experts getting real-world jobs.

Collapse
 
slizzard profile image
Slizzard

I've been in the industry for a decade and still need to review from time to time. That said, great work, and I'm keeping this article in my favorites!

Collapse
 
tamerlan profile image
Tamerlan

Thanks, appreciate it :D

Collapse
 
segebee profile image
Segun Abisagbo

I really enjoyed reading this.

love how you broke it down

Collapse
 
vijayvenkatanarayan profile image
VijayVenkataNarayan

Thank you.. very informative!

Collapse
 
kabircse profile image
Kabir Hossain • Edited

I have a question on your given line

"Imagine that one of the players got access to this client, and wanted to cheat by changing the game status and reward.
public static void client() {
Quest quest = new Quest('Goblin Slaying', 190, 3);
quest.reward = 1000000000;
quest.status = 5;
}
Right now this code is valid, because our variables are publicly accessible. Another problem here is that our "hacker" set the status to 5 which doesn't exist, and thus our game breaks."

My questions are given below:

  1. How player accessed the client because it is an application and the code is generated already and the system just call the instance?

  2. How hacker will access and alter this code? Because the application is generated an instance of this class and just run only.

Collapse
 
tamerlan profile image
Tamerlan

This was hypothetical, but it may be possible to inject java code to some game but idk, I used this example to explain encapsulation.

Collapse
 
wadigzon profile image
WADIGZON DIAZ-WONG • Edited

excellent overview. nice read for someone trying to brush up on these concepts!

Collapse
 
eduardocribeiro profile image
Eduardo Ribeiro

Great article! Got my like :)

Collapse
 
tamerlan profile image
Tamerlan

Thanks :D

Collapse
 
greengrer profile image
Greengrer

Thanks, this is very cohesive
Usually it's
"what is encapsulation" - theory
"how is it implemented in java" - access modifiers
"why is it important" -

And then
"why do you put private on a field" - idk, teacher said to always have the least access to things possible, idk why

Thank you for binding it together for dummies(I searced for oop principles in java for dummies)

Collapse
 
iggredible profile image
Igor Irianto

Great writing! Can't go wrong with the basics (and I forgot the basics all the time :D)

Collapse
 
greengrer profile image
Greengrer

Side question:
Do you think that being able to add function insides to interface method declaration through keyword default

default void printHi() {
sout("Hi!");
}

makes abstract classes kinda useless?

Collapse
 
danielkakai profile image
DANIELKAKAI

Thanks for refreshing my knowledge