@vasIvas

Нужно ли в javascript думать о private свойствах и методах?

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

Впитав концепцию классов в других языках, мне очень сложно себя перестроить. На первый взгляд, как мне казалось, очень легкий и простой js, превратился для меня в болото, из которого я только выбравшись, попадаю снова. И для меня самое сложное было не контекст и прототипное наследование, а отсутствие классов и модификаторов доступа.
С первого дня я смерился с отсутствием private, но что-то тянуло меня разобраться и я с Вашей помощью выяснил, что private все же можно воссоздать, но и это меня тоже не успокоило. Сегодня я полез на githab и начал смотреть код известных фраймворков и не увидел там приватных свойств.

И этот факт подтолкнул меня задать этот вопрос, но прежде я немножечко расскажу, что я хочу услышать.

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

И теперь и я хочу спросить - нужно ли заморачиваться на private в js
или стоит принять за правило, что в js просто не нужны эти приваты?

Когда я спрашиваю "нужны ли приваты", то подразумеваю не какой-то частный случай, а спрашиваю "нужно ли, как под копирку, создавать все объекты с приватными свойствами и методами, как если бы я это делал в языках с классами?"

Или же private нужно и Вы сами применяете только в частных случаях?
  • Вопрос задан
  • 2523 просмотра
Решения вопроса 3
@bromzh
Drugs-driven development
В питоне вообще нет модификаторов доступа, и все поля доступны по прямому доступу. И ничего страшного в этом нет. В js такая же ситуация. Более того, все эти заморочки с private заставляют зачастую генерить кучу геттеров и сеттеров, которые будут нарушать инкапсуляцию. Так что заморачиваться не стоит, ведь даже в яве можно с помощью ухищрений добраться до приватных полей через рефлексию.

Решение может быть таким: обозначать какие-то внутренние переменные и методы с символа подчёркивания. Они по-прежнему будут публичными, но для разработчика это знак, что такое поле не понадобится при использовании твоей библиотеки. А методы и переменные, необходимые только для одного публичного метода какого-нибудь класса можно делать локальными, чтобы не плодить кучу полей.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Инкапсуляция это всегда хорошо. Вопрос в том нужны ли вам приватные методы и свойства? Они хороши в контексте классов, что бы разграничить интерфейс и реализацию. В JS же объект является интерфейсом. То есть он не может иметь скрытого состояния. Точнее может но не в самом объекте, а в другом каком...

В Python-мире есть такая точка зрения по поводу отсутствия модификаторов досупа, которая выражается выражением "We're all consenting adults here" (все мы тут взрослые люди). То есть по мнению большинства поставить _ перед названием приватных методов достаточно что бы разработчики их не использовали. В JS даже это крайне не рекомендуется делать, так как у вас есть скоупы и все что нужно спрятать вы можете сокрыть там. Так же в ES6 появится WeakMap которые помогут хоть немного упростить разруливание скрытого состояния и уменьшит вероятность утечек памяти.

Если посмотреть на фреймворки, например AngularJS активно использует $$ перед именем приватного свойства или метода. Причем в добавох в jsdoc эти свойства отмечены как private и если указать соответствующие опции для минификаторов, то те переименуют эти свойства и тогда разработчику будет уже тяжело предсказать как оно будет называться в следующем релизе.
Ответ написан
UbuRus
@UbuRus
Инкапсуляция нужна.
largescalejs.ru
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы