Инкапсуляция полей данных помогает предотвратить ошибки программирования

From Wikipedia, the free encyclopedia

public class NormalFieldClass {
    public String name;
 
    public static void main(String[] args)
    {
        NormalFieldClass example1 = new NormalFieldClass();
        example1.name = "myName";
        System.out.println("My name is " + example1.name);
    }
}

public class EncapsulatedFieldClass {
    private String name;
 
    public String getName()
    {
        return name;
    }
 
    public void setName(String newName)
    {
        name = newName;
    }
 
    public static void main(String[] args)
    {
      EncapsulatedFieldClass example1 = new EncapsulatedFieldClass();
      example1.setName("myName");
      System.out.println("My name is " + example1.getName());
    }
}

From Wikipedia, the free encyclopedia

public class NormalFieldClass {
    public String name;
 
    public static void main(String[] args)
    {
        NormalFieldClass example1 = new NormalFieldClass();
        example1.name = "myName";
        System.out.println("My name is " + example1.name);
    }
}

public class EncapsulatedFieldClass {
    private String name;
 
    public String getName()
    {
        return name;
    }
 
    public void setName(String newName)
    {
        name = newName;
    }
 
    public static void main(String[] args)
    {
      EncapsulatedFieldClass example1 = new EncapsulatedFieldClass();
      example1.setName("myName");
      System.out.println("My name is " + example1.getName());
    }
}

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я углублюсь в четыре столпа (фундаментальных принципа ) объектно-ориентированного программирования:

• Инкапсуляция (эта статья)
• Наследование
• Полиморфизм
• Абстракция

Почему? Я считаю, что это знание необходимо не только разработчикам, но и несомненно тестировщикам, работающим с кодом, читающим или пишущим его. Понимание этих принципов позволяет вам лучше понимать код приложения, давать рекомендации по улучшению его структуры и, конечно, лучше писать код автотестов.

Примеры, которые я даю, в основном будут на Java, но в ходе этой серии статей я упомяну, как внедрять эти концепции, по возможности, в C# и Python.

Что такое инкапсуляция?

Инкапсуляция – это практика сокрытия деталей реализации, или внутреннего состояния, объекта и выборочное разрешение доступа к этим внутренним механикам через публичные методы. Инкапсуляция обычно применяется для предотвращения прямого доступа пользователей к объекту и изменению его свойств, зачастую в целях безопасности или предотвращения порчи данных.

Инкапсуляция: пример

Чтобы проиллюстрировать концепцию инкапсуляции и ее важности, предположим, что у нас есть класс Account, представляющий собой банковский счет, с двумя свойствами: тип счета (моделируется с использованием enum Account Type, который может принимать значения CHECKING и SAVINGS), и баланс счета, моделируемый как число двойной точности. Крайне наивная реализация такого класса может выглядеть примерно так:

public class Account {

    public AccountType type;
    public double balance;

    public Account(AccountType type) {
        this.type = type;
        this.balance = 0;
    }
}

Прямолинейно, но вызывает ряд вопросов. Самый важный из них заключается в том, что все пользователи этого класса могут обновлять значение свойства баланса, как им захочется, выполняя действия по депозиту или снятию средств, а это, возможно, не лучшая идея… Нет никакой гарантии, что верно соблюдаются бизнес-правила, так как такая реализация никоим образом не навязывает «правильное поведение».

Куда лучшим вариантом будет применить инкапсуляцию. Чтобы это сделать, мы сделаем сами свойства скрытыми, ограничивая прямой доступ к ним самим классом Account. Затем мы выдадим доступ к свойству через публичные методы, попутно навязывая ряд бизнес-правил:

public class Account {

    private AccountType type;
    private double balance;

    public Account(AccountType type) {
        this.type = type;
        this.balance = 0;
    }

    public double getBalance() {
        return this.balance;
    }

    public void deposit(double amount) throws DepositException {
        if (amount < 0) {
            throw new DepositException("You cannot deposit a negative amount!");
        }
        this.balance += amount;
    }

    public void withdraw(double amount) throws WithdrawException {
        if (amount < 0) {
            throw new WithdrawException("You cannot withdraw a negative amount!");
        }
        if (amount > this.balance && this.type.equals(AccountType.SAVINGS)) {
            throw new WithdrawException("You cannot overdraw on a savings account!");
        }
        this.balance -= amount;
    }
}

При использовании инкапсуляции и навязывания бизнес-правил становится невозможным снять отрицательную сумму или положить ее на счет. Также невозможно превысить баланс сберегательного счета. Текущий баланс все еще доступен публично, но теперь доступ ограничен чтением.

Это значительно снизит нежелательное поведение в системе. Однако все равно стоит написать ряд тестов для этого класса!

Инкапсуляция на других языках

В C# вы можете сделать нечто подобное тому, что мы уже рассмотрели в Java. В качестве примера я, возможно, инициализирую свойство баланса вот так:

public double Balance { get; private set; }

Это дает окружающему миру доступ для чтения самого свойства баланса, но обновляться оно сможет только изнутри самого класса Account. Как и в примере с Java, мы можем затем выдать доступ к балансу через публичные методы Deposit (число двойной точности) и Withdraw (число двойной точности), которые принуждают к исполнению требуемой бизнес-логики.

Python использует иную философию инкапсуляции. По умолчанию все в Python публично, что означает, что инкапсуляцию нельзя строго навязать. Есть, однако, соглашения, которые позволяют вам просигнализировать, что со свойствами надо обращаться осторожно.

Добавление префикса _ к свойству сообщает, что свойство нельзя не то что изменять, а даже просматривать извне класса. Повторюсь, это соглашение, не то, что выбито в камне, поэтому это возможно.

class Account:
    def __init__(self, type):
        self._type = type
        self._balance = 0

Чтобы действительно, действительно сообщить, что свойство приватно, можно добавить двойной префикс (__). Это делает свойство невидимым для пользователей класса (на него нельзя напрямую сослаться, скажем, через account.balance), но все еще не предотвращает доступ стороннего кода, потому что все еще существует подгонка имен Python. По сути доступ к свойству __balance объекта счета типа Account все еще можно получить через account._Account__balance.

Инкапсуляция в автоматизации

Вероятно, наиболее известное и широко используемое применение принципа инкапсуляции в автоматизации – это Page Object, широко используемые в автоматизации через пользовательский интерфейс при помощи таких инструментов, как Selenium Web Driver, Playwright и Cypress.

Page Object – это классы, инкапсулирующие детали реализации страницы, особенно локаторы, использующиеся для идентификации элементов на странице и применяющиеся в тестах. Затем Page Object дают доступ к этим методам через публичные методы. Делая это, они навязывают «бизнес-логику» в форме последовательности, с которой идет взаимодействие с объектами.

Вот пример объекта LoginPage (в Selenium WebDriver), прячущего детали реализации (локаторы элемента) в частных свойствах, и дающего доступ к ним через обычные тест-действия, определенные в публичных методах (в этом случае это авторизация в приложении через метод loginAs()):

public class LoginPage {

    private final By textfieldUsername = By.name("username");
    private final By textfieldPassword = By.name("password");
    private final By buttonDoLogin = By.xpath("//input[@value='Log In']");

    public LoginPage(WebDriver driver) {

        driver.get("https://parabank.parasoft.com/parabank");
    }

    public void loginAs(String username, String password) {

        sendKeys(textfieldUsername, username);
        sendKeys(textfieldPassword, password);
        click(buttonDoLogin);
    }
}

«Пользователь» такого класса Page Object (обычно тест-метод) может затем взаимодействовать с элементами, определенными в классе, только через публичный метод, не имея прямого доступа к (и без нужды заморачиваться с) деталям внедрения страницы – таким, как структура HTML и любая синхронизация состояния элементов. Это приводит к чистому API для класса page object и лучшему разделению интересов.

В следующей статье я глубже разберу второй из четырех фундаментальных принципов объектно-ориентированного программирования: наследование.

Обсудить в форуме

Инкапсуляция в программировании — это принцип, согласно которому внутреннее устройство сущностей нужно объединять в специальной «оболочке» и скрывать от вмешательств извне. Доступ к объектам возможен через специальные открытые методы, а напрямую обратиться к их содержимому нельзя.

Инкапсуляцию также описывают как принцип разделения логики и поведения. Логика — то, как что-то устроено внутри. Поведение — то, как оно взаимодействует с другими сущностями. Разделение этих двух понятий упрощает взаимодействие объектов в коде.

Обычно содержимое заключается в специальную программную оболочку, которая закрывает данные от внешних обращений. Принцип похож на автоматическую коробку передач: вам не приходится вручную управлять каждым элементом системы, более того — во время управления машиной к ним нет доступа. Есть только коробочка с рычагом, в качестве которой в программировании выступают открытые методы. Это понятно из названия: сущность оказывается «в капсуле», изолированной от внешнего мира.

Для чего нужна инкапсуляция

Инкапсуляция считается одним из четырех основных принципов ООП — объектно-ориентированного программирования. Этот подход представляет сущности в коде как классы и объекты, позволяет «строить» код из них, как из кирпичиков. Но чтобы объекты грамотно выполняли свои задачи и не ломались, нужна инкапсуляция.

Объяснить ее значимость поможет подход «от обратного». Вот как выглядела бы работа с кодом без инкапсуляции:

• Логика и поведение не разделяются — это значит, что если объект должен взаимодействовать с другим, ему придется учитывать его структуру;
• В любой объект можно обратиться извне напрямую — просто изменить внутреннюю переменную или сделать что-то еще;
• В результате код усложняется, а внутри объектов возникает путаница, которая может привести к ошибкам.

Поэтому инкапсуляция нужна — так код становится более упорядоченным и повышается отказоустойчивость. Ведь если сломается инкапсулированный объект, это не повлияет на работу других. Примерно как сломанная кнопка не приводит к поломке всего устройства.

Инкапсуляция, абстракция и сокрытие данных

При чем тут абстракция. Инкапсуляция тесно связана с понятием абстракции данных — одним из самых старых принципов ООП. Это понятие говорит, что любая сущность должна описываться каким-то минимумом ее возможностей. Мелкие особенности уже не важны для создания полного описания. Например, чтобы пользоваться телефоном, нам неважно, какого он цвета — с точки зрения функциональности это неважный параметр.

Абстракция помогает работать с объектами и не обращать внимания на то, как они устроены внутри. А для этого как раз нужна инкапсуляция.

Отличие от сокрытия данных. Но из определения абстракции необязательно следует сокрытие данных. Поэтому сейчас считается, что сокрытие данных от воздействий извне и инкапсуляция — немного разные вещи. Они различаются целью:

• Сокрытие нужно, чтобы обеспечить безопасность данных, и подразумевает невозможность доступа;
• Инкапсуляция нужна, чтобы обеспечить целостность объекта и дать возможность пользоваться им, не вдаваясь в подробности его реализации. При этом технический доступ к объекту в некоторых случаях может сохраниться.

Соответственно, различаются и реализации обоих принципов. Хотя тут многое зависит от языка программирования: в некоторых языках, например, C++, инкапсуляция без сокрытия считается бессмысленной. А в других, таких как Python, есть инкапсуляция, но нет сокрытия. Есть и языки, которые жестко разделяют два понятия — так, что они описываются по-разному.

Как выглядит реализация инкапсуляции

Идея инкапсуляции реализована в ООП с помощью классов и объектов. Класс — это абстрактное описание, по которому создаются объекты, работающие в коде. Его можно сравнить с чертежом, который описывает, как будет работать та или иная сущность. В то же время объекты — реальные переменные, которые хранят в себе данные, выполняют функции и работают. Можно сказать, это экземпляры техники, созданные по чертежам-классам.

Такое разделение помогает инкапсуляции — создает отдельную сущность, в которую входит определенный набор функций и данных. Класс описывает эту сущность с помощью идеи абстракции, о которой мы говорили выше. Получается целостный законченный объект, который работает без вмешательства других.

Функции внутри объекта называются методами, а данные — свойствами. Они разные, но объединены внутри одной сущности, как и предписывает принцип инкапсуляции.

Как разработчики инкапсулируют данные

Методы и свойства. Мы уже говорили о том, что классы и объекты — важный инструмент инкапсуляции. Стоит рассказать подробнее о методах и свойствах объектов. За счет них во многом обеспечивается инкапсуляция.

• Свойства — это переменные, «лежащие» внутри объектов. Они могут быть любого типа, а иногда и сами являются объектами. В переменных хранятся данные. Если какая-то переменная является свойством, ее содержимое по умолчанию скрыто. Как открывать и запрещать доступ к свойствам, мы расскажем ниже.
• Методы — это функции внутри объектов. Они не просто хранят данные, а совершают какое-то действие. Важное отличие метода от обычной функции — его можно вызвать только для объекта, в котором он находится. Вызов метода отличается и внешне: в большинстве языков сначала пишется имя объекта, а потом, через точку — название метода и аргументы. А еще для вызова метода ничего не нужно импортировать — все уже есть в объекте, и это еще один пример целостности инкапсулированной сущности.

Геттеры и сеттеры. Выше мы говорили, что свойства по умолчанию скрыты от посторонних. Несмотря на то что во многих случаях обратиться к ним напрямую через объект можно, в ООП это считается не лучшей практикой. Поэтому для работы со свойствами используют специальные методы — геттеры и сеттеры. Названия таких методов обычно начинаются со слов get и set — другие имена не запрещены синтаксисом, но считаются плохим тоном.

• Геттер — это метод объекта, который возвращает значение свойства этого объекта. Например, у объекта в свойстве value написано 15. Тогда геттер getValue() будет возвращать 15.
• Сеттер — это метод, который изменяет значение свойства, задает его (set). Например, гипотетический метод setValue(x) будет менять значение свойства value. Аргумент x — это новое значение свойства, при вызове сеттера туда подставляются данные.

Геттеры и сеттеры важны для инкапсуляции, потому что позволяют не вмешиваться во внутреннюю структуру объекта. Они работают с ним сами, а значит, нет нужды «лезть» в объект извне — данные передадут геттеры и сеттеры. Так снижается риск ошибки при работе с данными в объекте.

Модификаторы доступа. Теоретически обратиться в объект снаружи кода можно, но тут есть свои детали. Поведение по умолчанию может различаться для разных языков, но обычно возможность доступа к объекту можно настроить. Программист в коде сам описывает правила доступа. Для этого используются специальные ключевые слова — модификаторы доступа.

Модификаторы тоже могут иметь разный синтаксис в зависимости от языка. Классическое обозначение, принятое в языках C и C++:

• public — объект, функция или метод доступны для всех. Другие сущности могут читать оттуда данные и изменять их. Свойство публичного объекта можно получить, просто написав его название через точку: <имя объекта>.<имя свойства>. С такими данными легко работать, для них не нужны геттеры и сеттеры, но информация оказывается уязвима.
• private — содержимое объекта доступно только для других его составных частей. Например, метод объекта может вызывать данные из этого же объекта напрямую — а какой-нибудь код снаружи уже не сможет.
• protected — содержимое объекта доступно ему самому и его производным, например, потомкам.

Модификаторы задаются в классе, который описывает объект. Их можно задать самому классу или его содержимому — разным методам и свойствам.

В некоторых языках, например, C#, есть еще вариант internal — доступ открыт только из одного файла. В других файлах нельзя будет создать такой объект. Такой модификатор задается классу.

Ключевые слова. Ряд языков поддерживает и другие возможности, способствующие инкапсуляции. Обычно они реализуются с помощью ключевых слов. Например, static дает возможность сделать метод класса статичным — и запускать, даже если объект этого класса не создан.

Слово abstract описывает неполные, «схематичные» сущности, которые используются, чтобы наследовать от них более подробные. Объект абстрактного класса нельзя создать. Зато можно отнаследовать от него несколько других классов и создать уже их объекты — для того абстрактные сущности и нужны.

А слово sealed, наоборот, «запечатывает» класс и запрещает создавать его потомков. Это нужно для защиты от ситуаций, когда наследование может сломать работу кода.

Как начать работать с инкапсуляцией

Инкапсуляция — это часть ООП, а ООП начинают глубоко изучать уже после знакомства с базовыми возможностями языка. Но некоторыми вещами, которые реализованы по принципу инкапсуляции, человек начинает пользоваться еще на ранних стадиях обучения. Например, стандартные методы встроенных объектов — сортировка массива, получение его длины и другие. Просто позже, на более глубоком уровне изучения, начинающий разработчик поймет, с чем все время имел дело.

Если вы интересуетесь IT — приглашаем на курсы! Выберите и получите новую профессию, востребованную на рынке.

Перевод статьи Eric Elliott — Encapsulation in JavaScript

Инкапсуляция — это объединение данных и методов, которые воздействуют на эти данные, так что доступ к этим данным ограничен извне. Или как описывает это Алан Кей, «инкапсуляция — это локальное хранение и защита и скрытие процесса состояния». В ООП это означает, что объект хранит свое состояние в приватном порядке, и только методы объекта имеют доступ для его изменения.

Если вы хотите изменить инкапсулированное состояние, вы не обращаетесь к нему напрямую и не изменяете реквизиты некоторых объектов. Вместо этого вы вызываете метод объекта, и, возможно, объект ответит обновлением своего состояния. Например, если вы создаете приложение с использованием Redux, вместо непосредственного управления моделью данных представления, вы отправляете сообщение, называемое действием, в хранилище данных. Redux контролирует когда и как обрабатывается это сообщение. Время и обработка этого сообщения контролируются для создания предсказуемых, детерминированных обновлений состояния. При наличии одинаковых сообщений в одинаковом порядке Redux всегда будет отображать одно и то же состояние.

Аналогично, когда вы хотите обновить состояние компонента React с помощью useState или setState, эти изменения не влияют непосредственно на состояние компонента. Вместо этого они ставятся в очередь потенциальные изменения состояния, которые применяются после завершения цикла рендеринга. Вы напрямую не устанавливаете состояние компонента React, это делает сам React;

Почему инкапсуляция?

В 1960-х и 1970-х программисты боролись с временными зависимостями и конфликтами ресурсов, вызванными попыткой совместного использовать одних и те же ресурсов памяти между различными операциями, выполняемыми в недетерминированных последовательностях. Они также были разочарованы необходимостью привязки кода к конкретному представлению структуры данных о состоянии программы.

В 1970-х годах Алан Кей был вдохновлен составными структурами данных из диссертации Ивана Сазерленда Sketchpad, разработанной в 1961–1963 годах в Массачусетском технологическом институте и Симуле, разработанной в 1960-х годах Оле-Йоханом Далем и Кристен Найгаард из Норвежского вычислительного центра в Осло. Алан Кей принимал участие в исследованиях и разработках ARPAnet, имел опыт работы в науке и математике и был особенно вдохновлен тем, как клетки инкапсулируются мембраной и передаются через передачу сообщений.

Все эти идеи собрались вместе, чтобы сформировать основы ООП: инкапсуляция и передача сообщений.

Проблема с разделяемым изменяемым состоянием состоит в том, что если ваше состояние ввода зависит от состояния вывода какой-либо другой инструкции и любых видов параллелизма, это создает условия гонки. Если вы измените порядок вызова инструкций, это может изменить результаты. Смешайте любой недетерминизм в последовательности, и в результате получится хаос: непредсказуемое, недоказуемое, на первый взгляд случайное состояние приложения. Иногда это работает. Иногда это не так.

Инкапсуляция является одним из подходов к решению этой проблемы.

Инкапсуляция также решает еще одну интересную проблему. Представьте, что у вас есть совокупность данных, которые нужно обработать. Один из способов сделать это — сначала выбрать структуру данных для представления. Если вы начнете с реализации (скажем, используете массив), и все, кто его использует, узнает о его структуре то это может создать тесную связь со структурой данных, что может затруднить изменение этой реализации позже. Что, если вы в конечном итоге захотите поменять массив на поток (stream), дерево или какую-то другую структуру данных? Если все узнают реализацию, это может быть слишком поздно.

Но когда мы инкапсулируем эти детали реализации за общедоступным интерфейсом, а затем все, кто использует объект, делают это только через его общедоступный интерфейс, позже легче будет изменить внутреннюю реализации. Для иллюстрации представьте, что у вас есть структура данных, в которой хранятся числа, и вам нужен способ умножения сохраненных значений на два:

// Эта реализация работает только с массивами
const doubleAllImperative = data => {
  const doubled = [];
  for (let i = 0, length = data.length; i < length; i++) {
    doubled[i] = data[i] * 2;
  }
  return doubled;
};

// То же самое что и выше но работает с чем угодно через оператор map
const doubleAllInterface = data => data.map(x => x * 2);
const box = value => ({
  map: f => box(f(value)),
  toString: () => `box(${ value })`
});

console.log(
  doubleAllInterface([2,3]), // [4, 6]
  doubleAllInterface(box(2)).toString(), // box(4)
);

Инкапсуляция может быть мощным инструментом, способным помочь вам предотвратить ошибки, возникающие из-за общего изменчивого состояния, а также уменьшить жесткую связь между компонентами и структурами данных, на которые они опираются. Это поможет вам соблюдать как минимум три ключевых принципа разработки программного обеспечения:

1. Избегайте общего изменяемого состояния. «Недетерминизм = параллельная обработка + изменяемое состояние» — Мартин Одерски, дизайнер языка программирования Scala
2. Программируйте интерфейс, а не реализацию. — Банда четырех, «Design Patterns: Elements of Reusable Object Oriented Software”»
3. Небольшое изменение требований должно приводить к соответственно небольшому изменению приложения. — N. D. Birrell, M. A. Ould, “A Practical Handbook for Software Development”

Когда Брендан Айх создал JavaScript в эти роковые 10 дней, кульминацией которых стал выпуск в 1995 году, он задумал две идеи:

• Использования языка программирования Scheme в браузере
• Все должно выглядеть как в языке Java

Scheme — это функциональный язык программирования — диалект LISP, который был элегантным небольшим языком в 1958 году. Поскольку Scheme поддерживала очень гибкие функции высшего порядка и замыкания, у нее был очень большой потенциал.

Java — это объектно-ориентированный язык на основе классов. От Java JavaScript получил понятие функций конструктора, (в конце концов) классы и ключевого слова new (среди прочего).

Так же Брендан Айх черпал свое вдохновение от языка программирования Self. От него он взял прототипное наследование, которые делают JavaScript гораздо более мощным и гибким, чем его аналогично названный, но в остальном дальний родственник, Java, но это уже другая история.

Спустя 23 года этот парадигмальный плавильный котел все еще немного неправильно понят. Одно из таких распространенных недоразумений связано с инкапсуляцией.

Прежде чем перейти к идиоматической инкапсуляции для объектов в JavaScript, я сначала хочу обратиться к общему понятию инкапсуляции. Давным-давно, до того, как многие разработчики JavaScript узнали о замыканиях, некоторые разработчики JavaScript заметили, что объекты JavaScript (и позже классы) не включают механизм для закрытых свойств.

До появления предложения о приватных полях (private fields proposal) в ECMAScript не было никакого способа создать честное приватное свойство для объектов в JavaScript. Вместо того, чтобы использовать замыкания, с помощью которых обычно создают приватные данные для объектов в JavaScript, некоторые разработчики решили обозначить частные свойства и методы, добавив к ним префикс подчеркивания, и это стало общепризнанным (хотя и неуклюжим и спорным) соглашением.

Это спорно по нескольким причинам:

Критические изменения: внутренние свойства и методы имеют тенденцию меняться чаще, чем общедоступные свойства и методы Для многих префиксных методов подчеркивания, например, myComponent._handleClick, ссылаются на методы, которые не предназначены для непосредственного вызова пользователями API. Вместо этого они используются только для внутреннего использования, и, как таковые, если их реализации меняются или полностью удаляются, эти разработчики не считают это серьезным изменением.

К сожалению для пользователей, многие новые разработчики не знают о соглашении префиксов подчеркивания, поэтому могут использовать свойства когда захотят. Так же опытные разработчики часто знают, что это значит, но думают: «Я знаю, что я делаю», и поэтому все равно буду их использовать, особенно если это обеспечивает очевидное решение текущей проблемы. Другими словами, большое количество людей игнорирует соглашение, и это приводит к более серьезным изменениям, чем необходимо.

Утечка деталей реализации: Помните пример выше, где мы изначально поддерживали только массивы, но теперь мы хотим расширить нашу поддержку для потоков? Что ж, если ваши пользователи имеют прямой доступ к базовым структурам данных, они могут создавать зависимости от этих структур данных, поэтому при первом обнаружении потока они будут очень удивлены, когда их код сломается.

Расширенная поверхность атаки для хакеров: в частности, для общедоступных API-интерфейсов добавление еще большего количества API, чем необходимо для использования вашего кода, расширяет доступные данные для использования злоумышленниками. Один из важнейших принципов обеспечения безопасности программного обеспечения ограничивает поверхность атаки только тем, что абсолютно необходимо. Если вы действительно намереваетесь использовать что-то только для внутреннего использования, оно не должно подвергаться внешнему воздействию.

Самодокументируемый код: Ваш общедоступный API должен быть максимально самодокументируемым. Один из способов сделать это — показать только те методы и свойства, которые вы собираетесь предоставить своим пользователям. Таким образом, пользователи не склонны использовать неподдерживаемые и недокументированные методы. Если вы используете соглашение о подчеркивании, вы полагаетесь на то, что пользователь знает, что это значит, и понимает, что вы не хотите что бы это было ими использовано. Если вы используете инкапсуляцию, вам не нужно беспокоиться об этом. Они не смогут использовать то, к чему у них нет доступа.

Настоящая инкапсуляция в JavaScript

Конечно, как известно JavaScript всегда поддерживал реальную инкапсуляцию данных. Очень легко объявить приватные данные в JavaScript.

Используем Замыкание

const createCounter = () => {
  // Переменная, определенная в области действия конструктора
  // является приватной для этой функции. 

  let count = 0;
  return ({
    // Любые другие функции, определенные в той же области, являются привилегированными:
     // Они оба имеют доступ к закрытой переменной `count`
     // определяется в любом месте их цепочки областей видимости 
    click: () => count += 1,
    getCount: () => count.toLocaleString()
  });
};
const counter = createCounter();
counter.click();
counter.click();
counter.click();
console.log(
  counter.getCount()
);

Привилегированный метод — это метод, который имеет доступ к закрытым данным внутри области действия функции (также известной как лексическая среда). Привилегированные функции и методы имеют доступ на основе ссылок к переменным внутри функции, даже после того, как функция завершилась. Эти ссылки являются действующими, поэтому, если состояние изменяется во внутренней функции, изменения переносятся в каждую привилегированную функцию. Другими словами, когда мы вызываем counter.click(), она изменяет значение, которое видит counter.getCount().

Можно даже наследовать приватное состояние, используя функциональные миксины.

Использование приватных полей

На момент написания этой статьи закрытые поля стали доступны в babel с включенной функцией stage-3. Они так же поддерживаются в Chrome, Opera, браузере Android и Chrome для Android, поэтому есть хороший шанс, что вы можете сделать что-то вроде этого:

class Counter {
  #count = 0
  
  click () {
    this.#count += 1;
  }
  getCount () {
    return this.#count.toLocaleString()
  }
}

const myCounter = new Counter();
myCounter.click();
myCounter.click();
myCounter.click();
console.log(
  myCounter.getCount()
);

Я все еще предпочитаю использовать фабричные функции на основе замыканий, и пока не использую классы с новой спецификации полей классов, но если вам действительно нужна инкапсуляция, и замыкания, то новые поля классов намного лучше, чем подчеркивания, потому что они не полагаться на соглашение и вместо этого обеспечивают истинную инкапсуляцию.

Эрик Эллиотт — автор книг «Composing Software» и «Programming JavaScript Applications». Как соучредитель EricElliottJS.com и DevAnywhere.io, он обучает разработчиков основным навыкам разработки программного обеспечения. Создает и консультирует команды разработчиков для криптографических проектов, а также вносит свой вклад в опыт разработки программного обеспечения для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC и ведущих исполнителей звукозаписи, включая Usher, Frank Ocean, Metallica и многих других.

Инкапсулировать то, что изменяется, нужно потому что это экономит время и силы на изменения того, что зависит от того, что может быть изменено.

Практический пример

Исходя из того, что под инкапсуляцией изменяемого обычно понимается абстрагирование в смысле скрытия конкретного принципа действия, можно предложить следующий пример.

Вы проектируете объект банковского счета, который сейчас работает с одной базой данных. Если представить что объект счета может работать с совершенной другой базой данных (или даже с текстовыми файлами), то, если вы сразу заложитесь на это при проектировании интерфейса этого объекта, вам не придётся переписывать код, который задействует объект счета.

<?php
class Account
{
    private $balance = 0;
    private $account = [];

    protected function save()
    {
        // сохраним в файл
        file_put_contents('account.txt', json_encode($this));
    }

    public function add($amount, $explanation)
    {
        $this->balance += $amount;
        $this->account[] = [$amount, $explanation];
        $this->save();
    }

    public function withdraw($amount, $explanation)
    {
        $this->balance -= $amount;
        $this->account[] = [-$amount, $explanation];
        $this->save();
    }

    /* Пропустим другие методы */
}

Если для изменения баланса счета вызывается метод, в числе параметров содержащий только сумму и обоснование, то пользователю объекта будет совершенно не нужно знать, к какой именно базе данных обращается объект счета чтобы сохранить изменения.

Например, этой функции нет никакой разницы от того, использует ли переданный её счет какую-то базу данных или файлы — вся разница в работе счета инкапсулирована:

<?php
class AccountConsumer
{
    function addToAccount(Account $account)
    {
        // этой функции нет никакой разницы от того, использует
        // ли счет какую-то базу данных или файлы - вся разница
        // в работе счета инкапсулирована
        $account->add($this->totalCharge, $this->getExplanation());
    }

    /* Пропустим другие методы */
}

Функция addToAccount будет одинаково хорошо работать как с экземпляром класса Account, так и с экземпляром класса DatabaseAccount:

<?php
class DatabaseAccount extends Account
{
    protected function save()
    {
        // сохраним в базу данных
        foreach ($this->account as list ($amount, $explanation)) {
            $this->database->updateRec($amount, $explanation);
        }
    }

    /* Пропустим другие методы */
}

Благодаря правильно спроектированному интерфейсу класса Account вы сможете как угодно менять принципы сохранения данных внутри Account без необходимости менять что-то в классах, использующих класс счета.

Зачем ещё это может быть нужно?

Кроме удобства для последующего изменения стоит учитывать и фактор когнитивной нагрузки на программиста. И абстрагирование, и сокрытие информации позволяют её снизить. Например, для использования того же объекта счета программисту не нужно думать ни о БД, ни об ручной обработке исключительных ситуаций. Инкапсуляция делает несущественными конкретные детали, которые программисту не нужно изменять, в идеальном случае полностью избавляя от необходимости думать о них.