Чистый javascript. Объекты и структуры данных. Асинхронность. Обработка ошибок

Реализуйте приватные свойства ваших объектов

Т.е. не "ребята, смотрите как можно организовать работу с приватными значениями", а "реализуйте". Повелительное наклонение. Брр… Это известный паттерн в JS, но не более того. Есть и другие. В данном случае вы ещё попробуйте увязать его с class-ми. Тут же в прошлой статье, кажется, речь шла про "используйте классы".

const Employee = function (name) {
  this.getName = function getName() {
    return name;
  };
};

О да. Создавайте новые методы при создании каждого экземпляра класса. К чёрту прототипы. Какие такие прототипы? Наследование? Какое-такое наследование? Зато у нас приватные поля. Ну да ладно. Такой подход имеет право на существование и даже активно используется. Но это даже не рекомендация. Это просто один из вариантов.

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

На этом моменте я просто поперхнулся. Чего? Что я сейчас читаю? Речь идёт не о "бывает удобно использовать get-ы и set-ы в некоторых исключительных ситуациях", а об "используйте их вместо полей повсеместно". На кой чёрт? Ах, да, там же написано:

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

Реализовать дольше? WAT? Russian. Do you speak it? Okay.

Т.е. если для получения значения по его имени вам внезапно потребуется нечто "дольшее", чем обратиться к той области памяти где это значение лежит… То логично, что вам потребуется поправить и какой-то другой код, который работает с этим. Т.е. было всё статично, быстро и предельно однозначно, очевидно. А теперь потребовалось разбавить всё это щепоткой логики. Это уже сама по себе ситуация дрянная. А автор предлагает эту поднаготную скрывать. За геттерами и сеттерами. Причём делать это заранее, исходя из "ну а вдруг понадобится, мало ли". Такого рвения расставлять себе повсюду грабли я ранее не встречал.

Валидацию легко реализовать на уровне реализации сеттера

С одной стороны легко. С другой стороны валидация это штука тонкая. Принудительно валидировать поле при его обновлении дело… сомнительное. Посудите сами: валидация нужна не всегда. Ой? Валидация может быть асинхронной. Ой? Валидация может быть несколько тяжёлой. Ой? Валидация может зависеть от ряда других полей? Дважды ой? Что если вы их последовательно устанавливаете сериализуя какой-то объект? Всё как-то сразу стало плохо и сложно. Делать валидацию по сеттеру можно. Но нужно? И часто ли это того стоит?

Инкапсуляция внутреннего состояния объекта

Не очень понял, что имелось ввиду. Мол в обычном поле нет логики, а в методе вы можете нагородить что угодно? Эмм… Ну да. Можете.

Легко добавить логирование и обработку ошибок на уровне геттеров и сеттеров

Скажем в целях профилирования или debug-нга, это имеет смысл. Но едва ли за их пределами. Напомню геттеры и сеттеры даже в самом простом виде штуки тяжёлые.

Наследуя этот класс, вы можете переопределить функциональность по умолчанию

И сделать и без того не очевидное поведение ещё более не очевидным. Даёшь больше багов богу багов.

Вы можете лениво подгружать свойства вашего объекта, например, с сервера.

Вот тут моя челюсть выпала повторно. Т.е. было поле .name и в нём было имя. А теперь… В зависимости от положения спутников Сатурна поле может вернуть как значение, так и… ничего, а само загрузить асинхронно (или ещё хуже — синхронно) что-то с какого-то сервера? Да вы (автор, не переводчик) в своём уме?

Геттеры и сеттеры интересные, и местами удобные, инструменты. Но такие… dark side. Их нужно использовать с умом и только в тех местах, где их многочисленные минусы с лихвой покрываются плюсами. В 99+% случаев если вам стало тесно в plain data, нужно писать методы, а не геттеры и сеттеры. И да, править код под это дело.

У меня только 1 вопрос. Это правда стоило того, чтобы это переводить?