You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/09-classes/04-private-protected-properties-methods/article.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,7 +50,7 @@ That was a general introduction.
50
50
51
51
In JavaScript, there are two types of object fields (properties and methods):
52
52
53
-
- Public: accessible from anywhere. They comprise the external interface. Till now we were only using public properties and methods.
53
+
- Public: accessible from anywhere. They comprise the external interface. Until now we were only using public properties and methods.
54
54
- Private: accessible only from inside the class. These are for the internal interface.
55
55
56
56
In many other languages there also exist "protected" fields: accessible only from inside the class and those extending it (like private, but plus access from inheriting classes). They are also useful for the internal interface. They are in a sense more widespread than private ones, because we usually want inheriting classes to gain access to them.
@@ -257,7 +257,7 @@ class MegaCoffeeMachine extends CoffeeMachine {
257
257
}
258
258
```
259
259
260
-
In many scenarios such limitation is too severe. If we extend a `CoffeeMachine`, we may have legitimate reason to access its internals. That's why protected fields are used more often, even though they are not supported by the language syntax.
260
+
In many scenarios such limitation is too severe. If we extend a `CoffeeMachine`, we may have legitimate reasons to access its internals. That's why protected fields are used more often, even though they are not supported by the language syntax.
261
261
262
262
````warn header="Private fields are not available as this[name]"
263
263
Private fields are special.
@@ -283,7 +283,7 @@ In terms of OOP, delimiting of the internal interface from the external one is c
283
283
284
284
It gives the following benefits:
285
285
286
-
Protection for users, so that they don't shoot themselves in the feet
286
+
Protection for users, so that they don't shoot themselves in the foot
287
287
: Imagine, there's a team of developers using a coffee machine. It was made by the "Best CoffeeMachine" company, and works fine, but a protective cover was removed. So the internal interface is exposed.
288
288
289
289
All developers are civilized -- they use the coffee machine as intended. But one of them, John, decided that he's the smartest one, and made some tweaks in the coffee machine internals. So the coffee machine failed two days later.
@@ -308,9 +308,9 @@ Hiding complexity
308
308
309
309
**It's always convenient when implementation details are hidden, and a simple, well-documented external interface is available.**
310
310
311
-
To hide internal interface we use either protected or private properties:
311
+
To hide an internal interface we use either protected or private properties:
312
312
313
313
- Protected fields start with `_`. That's a well-known convention, not enforced at the language level. Programmers should only access a field starting with `_` from its class and classes inheriting from it.
314
-
- Private fields start with `#`. JavaScript makes sure we only can access those from inside the class.
314
+
- Private fields start with `#`. JavaScript makes sure we can only access those from inside the class.
315
315
316
316
Right now, private fields are not well-supported among browsers, but can be polyfilled.
0 commit comments