Question:
What is Encapsulation?
Quick answer:
Encapsulation can be used in any meaning of any of these terms or both:
- Mechanism used to restrict access to some of an object's properties.
- Mechanism that allows data access only via related methods or functions (setters and getters).
Longer answer:
Basically, the first definition is only about creating private properties.
Btw there are no private properties in JavaScript but looks like there is a proposal. In Typescript private properties are present.
UPD: as @scott_yeatts has mentioned in the comments, it is still possible to use private properties in JavaScript via The Revealing Module Pattern.
Another definition is just a way to say that access to every property is implemented via getters and setters.
class User {
private salary = 0;
setSalary(salary: number) {
this.salary = salary
}
getSalary() {
return this.salary
}
}
let user = new User()
console.log(user.getSalary()) // 0
user.setSalary(10)
console.log(user.getSalary()) // 10
Real-life applications:
This getters & setters pattern was always confusing to me and felt like a total redundancy, haven't changed my opinion still.
There is a list with a bunch of good reasons why getters & setters can be useful, but I can't say that I actually had an issue with any of the described topics.
// Here goes super opinionated section
Feels like the whole industry is moving to not deeply using OOP and preferring immutable objects and pure functions over data mutations, so this topic maybe just a tribute to old times π€·
// end of super opinionated section
If you know a good example of beneficial use of getters and setters, please share it in the comments π
Resources:
wiki/encapsulation
tutorialspoint/java/encapsulation
Other posts:
- JS interview in 2 minutes / Polymorphism (OOP)
- JS interview in 2 minutes / Inheritance in OOP
- JS interview in 2 minutes / Object-Oriented Programming (OOP)
Btw, I will post more fun stuff here and on Twitter. Let's be friends π
Top comments (2)
While it's true that JS doesn't have private properties, but this is a solved problem (No Typescript necessary!)
Use the Revealing Module design pattern, and you can have a public/private API for your module.
That said, I also believe JavaScript is trending more towards the Functional Programming world, and I'm an advocate for that direction. That doesn't mean that OOP is outdated or not something to learn, just that I don't think it's the best fit for most (but not all) JS applications.
I can't wait for the industry to reach a better balance between functional approaches, which are GREAT for stateless, event driven actions (IE: Your typical microservices web backend) and OOP which are much better suited for stateful, context dependent actions (Like you might see in an application designed to run independently without API support, like a desktop app or a game).
Both are useful, but I've seen a lot of people trying to use one or the other as a hammer, when all they have are a box of screws!
Thanks for the comment! I've added a note about the Revealing Module pattern to the post itself and mentioned you π Thanks again!
Totally agree with you, the right tool, for the right need!