правки

Author: egorzot

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

@@ -1,5 +1,5 @@
 
-# Приватные и защищённе методы и свойства
+# Приватные и защищённые методы и свойства
 
 Один из важнейших принципов объектно-ориентированного программирования -- разделение внутреннего и внешнего интерфейсов.
 
@@ -19,17 +19,17 @@
 
 ![](coffee-inside.jpg)
 
-Множество деталей. Но мы можем пользоваться ею ничего об этом не зная.
+Множество деталей. Но мы можем пользоваться ею, ничего об этом не зная.
 
-Кофеварки довольно надежны, не так ли? Мы можем пользоваться ими годами, и если что то пойдёт не так - отнесём в ремонт.
+Кофеварки довольно надежны, не так ли? Мы можем пользоваться ими годами, и если что-то пойдёт не так - отнесём в ремонт.
 
 Секрет надёжности и простоты кофеварки -- все детали хорошо отлажены и *спрятаны* внутри.
 
-Если мы снимем защитную крышку с кофеварки, то пользоваться ею будет гораздо сложнее (куда нажимать?) и опасно (может привести к поражению электрическим током).
+Если мы снимем защитный кожух с кофеварки, то пользоваться ею будет гораздо сложнее (куда нажимать?) и опаснее (может привести к поражению электрическим током).
 
 Как мы увидим, в программировании объекты похожи на кофеварки.
 
-Но, чтобы скрыть внутренние детали, мы будем использовать не защитную крышку, а специальный синтаксис языка и соглашения.
+Но, чтобы скрыть внутренние детали, мы будем использовать не защитный кожух, а специальный синтаксис языка и соглашения.
 
 ## Внутренный и внешнией интерфейсы
 
@@ -42,7 +42,7 @@
 
 Внутренний интерфейс используется для работы объекта, его детали используют друг друга. Например, трубка кипятильника прикреплена к нагревательному элементу.
 
-Но снаружи кофеварка закрыта защитной крышкой, так что никто этого не может до этого добраться. Детали скрыты и недоступны. Мы можем использовать их функции через внешний интерфейс. 
+Но снаружи кофеварка закрыта защитным кожухом, так что никто не может добраться до сложных частей. Детали скрыты и недоступны. Мы можем использовать их функции через внешний интерфейс. 
 
 Итак, всё, что нам нужно для использования объекта, это знать его внешний интерфейс. Мы можем совершенно не знать, как это работает внутри, и это здорово.
 
@@ -53,15 +53,15 @@
 - Публичные: доступны отовсюду. Они составляют внешний интерфейс. До этого момента мы использовали только публичные свойства и методы.
 - Приватные: доступны только внутри класса. Они для внутреннего интерфейса.
 
-Во многих других языках также существуют «защищённые» поля: доступные только внутри класса и тех, которые его расширяют. Они также полезны для внутреннего интерфейса. В некотором смысле они более распространены, чем приватные, потому что мы обычно хотим, чтобы наследующие классы получали доступ к внутренним полям для правильного выполнения расширения.
+Во многих других языках также существуют «защищённые» поля, доступные только внутри класса или для дочерних классов. Они также полезны для внутреннего интерфейса. В некотором смысле они более распространены, чем приватные, потому что мы обычно хотим, чтобы наследующие классы получали доступ к внутренним полям для правильного выполнения расширения.
 
 Защищённые поля не представлены в JavaScript на уровне языка, но на практике они очень удобны, поэтому их эмулируют. 
 
 В следующей главе мы будем делать кофеварку на JavaScript со всеми этими типами свойств. Кофеварка имеет множество деталей, мы не будем их моделировать для простоты примера (хотя могли бы).
 
 ## Защищённое свойство "waterAmount"
 
-Давайте для начала создадим простой класс Кофеварка:
+Давайте для начала создадим простой класс для описания кофеварки:
 
 ```js run
 class CoffeeMachine {
@@ -81,7 +81,7 @@ let coffeeMachine = new CoffeeMachine(100);
 coffeeMachine.waterAmount = 200;
 ```
 
-Прямо сейчас своства `waterAmount` и `power` публичные. Мы можем легко получать и устанавливать им любое значение извне.
+Прямо сейчас свойства `waterAmount` и `power` публичные. Мы можем легко получать и устанавливать им любое значение извне.
 
 Давайте изменим свойство `waterAmount` на защищённое, чтобы иметь больше контроля над ним. Например, мы не хотим, чтобы кто-либо устанавливал его ниже нуля.
 
@@ -125,7 +125,7 @@ coffeeMachine.waterAmount = -10; // Error: Отрицательное колич
 
 Этот случай идеально подходит для кофеварки: мощность никогда не меняется.
 
-Доя этого нам нужно создать только геттер, а сеттер не создавать:
+Для этого нам нужно создать только геттер, а сеттер не создавать:
 
 ```js run
 class CoffeeMachine {
@@ -178,7 +178,7 @@ new CoffeeMachine().setWaterAmount(100);
 ```smart header="Защищённые поля наследуются"
 Если мы унаследуем `class MegaMachine extends CoffeeMachine`, ничто не защитит нас от доступа к `this._waterAmount` или `this._power` из методов нового класса.
 
-Таким образом защищённые методы конечно же наследуются. В отличие от приватных полей, в чем мы убедимся ниже.
+Таким образом защищённые методы, конечно же, наследуются. В отличие от приватных полей, в чём мы убедимся ниже.
 ```
 
 ## Приватное свойство "#waterLimit"
@@ -270,7 +270,7 @@ class CoffeeMachine extends CoffeeMachine() {
 }
 ```
 
-Во многих случаях такое ограничение слишком жестко. Если мы расширяем `CoffeeMachine`, у нас может быть законная причина для доступа к внутренним методам и свойствам. Поэтому в большинстве случаев используются защищённые свойства, даже если они не поддерживаются синтаксисом языка.
+Во многих случаях такое ограничение слишком жёсткое. Если мы расширяем `CoffeeMachine`, у нас может быть законная причина для доступа к внутренним методам и свойствам. Поэтому в большинстве случаев используются защищённые свойства, даже если они не поддерживаются синтаксисом языка.
 
 ````warn
 Приватные поля особенные.
@@ -293,28 +293,28 @@ class User {
 
 В терминах ООП разделение внутреннего интерфейса от внешнего называется [инкапсуляция](https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5).
 
-Это дает следующие выгоды:
+Это даёт следующие выгоды:
 
 Защита для пользователей, чтобы они не выстрелили себе в ногу
-: Представьте себе,что есть команда разработчиков, использующая кофеварку. Она была изготовлена компанией «Best CoffeeMachine» и работает нормально, но защитная крышка была снята. Внутренний интерфейс обнажен.
+: Представьте себе, что есть команда разработчиков, использующая кофеварку. Она была изготовлена компанией «Best CoffeeMachine» и работает нормально, но защитный кожух была снята. Внутренний интерфейс стал доступен извне.
 
     Все разработчики культурны -- они используют кофеварку по назначению. Но один из них, Джон, решил, что он самый умный, и сделал некоторые изменения во внутренностях кофеварки. После чего кофеварка вышла из строя через два дня.
 
-    Это, конечно, не вина Джона, а скорее человека, который снял защитную крышку и позволил Джону делать свои манипуляции.
+    Это, конечно, не вина Джона, а скорее человека, который снял защитный кожух и позволил Джону делать свои манипуляции.
 
     То же самое в программировании. Если пользователь класса изменит вещи, не предназначенные для изменения извне -- последствия непредсказуемы.
 
 Поддерживаемость
-: Ситуация в программировании сложнее, чем с реальной кофеваркой, потому что мы не просто покупаем ее один раз. Код постоянно подвергается разработке и улучшению.
+: Ситуация в программировании сложнее, чем с реальной кофеваркой, потому что мы не просто покупаем её один раз. Код постоянно подвергается разработке и улучшению.
 
     **Если мы строго разграничим внутренний интерфейс, то разработчик класса может свободно изменять его внутренние свойства и методы, даже не информируя пользователей..**
 
-    Гораздо проще разрабатывать, если вы знаете, что определенные методы можно переименовывать, их параметры можно изменять и даже удалять, потому что от них не зависит внешний код.
+    Гораздо проще разрабатывать, если вы знаете, что определённые методы можно переименовывать, их параметры можно изменять и даже удалять, потому что от них не зависит внешний код.
 
-    С выходом новой версии вы можете подностью все переписать, но для пользователя будет просто обновиться, если внешний интерфейс остался такой же.
+    С выходом новой версии вы можете полностью всё переписать, но пользователю надо будет просто обновиться, если внешний интерфейс остался такой же.
 
 Сокрытие сложности
-: Люди обожают использовать простые вещи. По крайней мере снаружи. Что внутри, это другое дело.
+: Люди обожают использовать простые вещи. По крайней мере, снаружи. Что внутри -- это другое дело.
 
     Программисты не являются исключением.