Skip to content

Commit 6f8ad3c

Browse files
authored
Update article.md
Grammar suggestions
1 parent 33cca1b commit 6f8ad3c

File tree

1 file changed

+5
-5
lines changed
  • 1-js/09-classes/04-private-protected-properties-methods

1 file changed

+5
-5
lines changed

1-js/09-classes/04-private-protected-properties-methods/article.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@ That was a general introduction.
5050

5151
In JavaScript, there are two types of object fields (properties and methods):
5252

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.
5454
- Private: accessible only from inside the class. These are for the internal interface.
5555

5656
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 {
257257
}
258258
```
259259

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.
261261

262262
````warn header="Private fields are not available as this[name]"
263263
Private fields are special.
@@ -283,7 +283,7 @@ In terms of OOP, delimiting of the internal interface from the external one is c
283283

284284
It gives the following benefits:
285285

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
287287
: 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.
288288

289289
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
308308

309309
**It's always convenient when implementation details are hidden, and a simple, well-documented external interface is available.**
310310

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:
312312

313313
- 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.
315315

316316
Right now, private fields are not well-supported among browsers, but can be polyfilled.

0 commit comments

Comments
 (0)