Скажите а в чём смысл приватных свойств объекта, если их так легко можно реализовать через замыкания?...
|
Цитата:
class A { field1; field2; constructor () {...} meth1 () {...} meth2 () {...} } Где вы опишите переменную, которую "замыкает"? |
Ну отсюда второй вопрос возникает :) В каких ситуациях использования классов, прям уж так необходимо?...
У меня опыт маленький, поэтому, могу чего-то не понимать, но случаев, где я не увидел, как обычные функции полноценно заменяют классы(то есть прекрасно прописывают прототипные ссылки), было, вроде, всего два: Первое. Когда у нас есть родитель и его метод. И есть наследник, и его метод. И нужно (желательно), чтоб метод наследника назывался также, и содержал в себе уточнённое поведение метода родителя. В этом случае, да, классы удобнее. Второе. Когда изучал конструктор ошибок. Без классового синтаксиса с его super добиться нормального наследования, не получилось. Но опять же, я не слишком искушён, возможно, просто плохо себе представлял чего куда прописывать. А так, иногда создаётся впечатления, что классы, призванные сделать синтаксис более простым и прозрачным, на деле, таковым являются, для решения каких-то достаточно типовых задачах. А настраивать их сложнее... Вот, как раз, в случае с замыканиями. Хочу реализовать приватные свойства, с помощью замыканий они делаются на раз, а без них? Левой ногой через правое ухо :) |
Сейчас добавили для классов настоящие приватные свойства вида:
#<имя>, раньше просто писали _<имя>и соглашались, что мол свойства начинающиеся на _считаем приватными и не трогаем снаружи.) P.S. Лично меня, как адепта монкипатчинга, раздражают эти нововведения. Учитывая среднее качество гонокода в вебе, иметь возможность запатчить что-то внутри - насущная необходимость.) |
Цитата:
Да и то не полностью. Например, даже в хроме пока нет конструкции o?.#x Пока нет приватных методов. Я правда не очень понимаю такую уж большую необходимость введения приватных свойств. Защищенные (protected) были бы более насущными и востребованными. |
Какие аспекты программирования плохо реализовывать с помощью модулей? По-идее, всё закрыто, выводим только то, что считаем нужным, расширяем дополняем модифицируем... В чём минусы? Почему такой большой акцент на классы?
|
Модули - это модули, классы - это классы.
Классы нужны для ООП. О преимуществах ООП написаны гигабайты, гуглите. Модули нужны для удобства разделения кода, не важно ООП вы используете или функциональщину. |
Ну как бы одно квадратное, а другое зеленое.
Как модули без использования классов (функций конструкторов) помогут создавать объекты с методами, свойствами, наследованием...? |
Цитата:
Надо вот это прочитать, в этой же книге есть пример из предыдущей ссылки: https://addyosmani.com/resources/ess...patterns/book/ Introduction What is a Pattern? "Pattern"-ity Testing, Proto-Patterns & The Rule Of Three The Structure Of A Design Pattern Writing Design Patterns Anti-Patterns Categories Of Design Pattern Summary Table Of Design Pattern Categorization JavaScript Design Patterns Constructor Pattern Module Pattern Revealing Module Pattern Singleton Pattern Observer Pattern Mediator Pattern Prototype Pattern Command Pattern Facade Pattern Factory Pattern Mixin Pattern Decorator Pattern Flyweight Pattern JavaScript MV* Patterns MVC Pattern MVP Pattern MVVM Pattern Modern Modular JavaScript Design Patterns AMD CommonJS ES Harmony Design Patterns In jQuery Composite Pattern Adapter Pattern Facade Pattern Observer Pattern Iterator Pattern Lazy Initialization Pattern Proxy Pattern Builder Pattern jQuery Plugin Design Patterns JavaScript Namespacing Patterns Conclusions References Цитата:
Цитата:
|
Цитата:
class C { #x = 42; x(o = this){ return o?.#x; } } return new C().x() === 42 && new C().x(null) === void 0; Взят отсюда https://kangax.github.io/compat-table/esnext/ Насколько это реально нужно? Кто его знает Возможно такая фиговина может понадобится. |
Часовой пояс GMT +3, время: 22:24. |