Это было очень сильное заявление. Оно очень точно описывает все программные продукты от IBM.
В java «хардкора» не меньше, чем в js, он просто другой =)
но обсуждение этого топика скатится в холивар)))
Как я писал ниже, есть настроения писать серьезные приложения на js с большими объемами логики (фактически заменить нативные приложения). Эти приложения должны быть Легкими в поддержке и Быстрыми в изучении.
Вот к примеру какая-нибудь программа для расчета бухгалтерии. Сейчас есть онлайн-решения, но они построены по принципу тонкого клиента. А ведь можно же сделать толстый клиент, который сможет работать оффлайн и не будет на каждый чих дергать бекэнд.
Объемы бизнес логики в бухгалтерском приложении неимоверные. А при текущем положении дел такое приложение будет состоять из сырых хеш таблиц и функций, которые с ними работают.
Но в целом да, можно сказать: «не хочу в такой проект, я хочу что-то классное!»
У static factory method немного другой смысл. Он предназначен, чтобы создавать закрытые библиотеки / фреймворки, который можно замокать, но нельзя расширить.
Это облегчает жизнь, когда нужно поддерживать обратную совместимость. Появляется возможность безболезненно менять строение внутренних классов, главное, чтобы они соответствовали интерфейсу. Можно добавлять, удалять, изменять имплементации (они внутренние и никто не может на них завязаться).
Пример тому в Java — EnumSet.
Позволяет создать множество из enum объектов. При необходимости, в метод, принимающий EnumSet можно передать мок или свою реализацию. Но вот залезть в этот «фреймворк» и каким-то образом изменить его стандартное поведение, не получится.
В зависимости от количества элементов в Enum, этот класс может выдать разные реализации, некоторые будут построены на битовой маске int, некоторые на битовой маске long, если 32 или 62 бита не хватит — можно использовать массив. Нужно будет создать множество из одного элемента — пожалуйста. Если тесты производительности покажут, что Конкретная имплементация для 2 элементов будет работать лучше, чем имплементация с битовой маской — можно добавить ее и просто обновив версию пользователь получит прирост производительности без каких либо изменений своего кода.
Ниже я уже ответил, что не DOM-манипуляцией едины. Есть желание писать действительно большие системы на js. Системы, которые позволили бы полностью заменить большинство нативных приложений. Но столь огромные приложения очень тяжело поддерживать, если нету системы классов и типов.
Класс из ES2015 (принято же так называть, а не ES6) действительно не столь хорош, каким бы мог бы быть. Я выше приводил пример языка, который был бы отличным путем развития.
class Foo {
private var _startPoint: {x: 5, y:10};
private var _callback:Function;
function set startPoint(startPoint) { this._startPoint = startPoint; }
function get startPoint() { return _startPoint; }
function set callback(func:Function) { _callback = func; }
}
Это лишь для демонстрации синтаксиса. Как видно, то, что вам не нравится в ES2015 в том же as3 реализовано так, как вам хотелось бы. Хотите — пишите в ES5, хотите пишите в виде ООП.
Т.к. это все же ES, никто не отменяет использование прототипов, можно уже существующим объектам подсунуть миксин.
Я не возражаю против этого, у js действительно свой увлекательный путь, который нужно полюбить.
Но! Почему-то миллионы леменгов хотят принести ООП и систему классов. Стоит посмотреть на старые библиотеки / фреймворки. Каждая из них вводит свой вариант создания Класса. jQuery, Backbone, Lodash, у них у всех свой путь к созданию эдакой системы типов. «Более современные» идут тем же путем.
Ответственные за развитие ES вводят классы. Может не все так хорошо с этим путем?
И ведь это все мы сейчас смотрим только с точки зрения веба (js для работы с DOM), тут и вправду можно обойтись ES5 и компонентным подходом к написанию кода.
Но кроме как для работы с DOM js используется еще и на бекенде (node.js | express.js). На js сейчас пишутся огромные веб-приложения с кучей бизнес логики (не только манипуляция с DOM). А еще игры пишут на js.
И вот для больших приложений и игр без объектной модели довольно тяжело будет обеспечивать поддержку.
Вот представим, что у нас есть Quake, написанный на js (Quake — это очень маленькое, по объемам логики, приложение). И у нас есть ошибка, конкретную точку, где она проявляется — мы знаем. Как найти все пути, которые приводят к этой точке кода?
К предыдущим двум ответам, стоит лишь добавить, что Абстрактный класс определяет иерархию («это есть», «является»), в то время, как Интерфейс лишь говорит о возможности («может»).
Самолет — это механизм.
Птица — это живое существо.
Самолет и Птица может летать (летающий объект).
В небе можно увидеть Летающие объекты.
А ведь не только новички не знают. Вот к новичкам претензий нету. Многие, у кого за плечами уже по 2-4 года не знают ответов на указанные вопросы.
А на счет застоя, я не соглашусь. Когда все будут знать ответы на базовые вопросы, тогда произойдет качественный скачек развития всего ИТ мира.
Вот только чтобы знать ответы на все базовые вопросы, нужно очень много времени потратить. «Программирование — это не работа, это образ жизни».
Вернее, не Декораторы, а мета-теги (аннотации). Декораторы из ES имеют все же более мощный синтаксис.
Мой посыл был в том, что можно же взять такой синтаксис за основу и просто прикрутить к нему синтаксический сахар в виде стрелочных функций, асинхронных функций и генераторов.
Меня всегда удивлял этот странный путь развития JS (ES).
Все js разработчики всегда плюются в сторону классов и типов, но при этом лучшие из них создают свою собственную систему классов / типов, а V8 под капотом типизирует создаваемые объекты.
Некоторые и вовсе собрались и создали TypeScript. Казалось бы крутая штука! Но как и все, что делается под эгидой Microsoft — сделано криво.
Дошло до того, что в ES2015 все же ввели классы, но не ввели типизацию (надеюсь, еще одумаются), теперь половина плюется, половина с радостью использует. Классы на самом деле хороши, но нету модификаторов доступа (public, private), которая иногда очень даже нужна. Нету полей класса, их можно объявить только через конструктор.
Почему все крутые чуваки в мире JS (ES) всегда стараются изобрести велосипед?
Вот уже много лет есть готовый язык, который основан на базе ES5, в котором есть Классы, Декораторы, Spread syntax, Поля классов, Модификаторы доступа, Интерфейсы. При этом язык позволяет создавать и использовать анонимные объекты и функции как в ES5, позволяет не описывать типы у параметров и возвращаемых значений, позволяет принимать любые значени (т.е. писать в ES5 стиле).
ActionScript3 — язык созданный на базе ES5, для Flash. Но сам синтаксис очень вкусный и без проблем подошел бы как путь развития синтаксиса ES.
На самом деле никто не насаждает писать только через описанные паттерны. Более того, никто даже не обязывает реализовывать паттерны 1 в 1 как в примерах. Пример написан лишь для понимания как это может выглядеть.
У всего хорошего всего есть побочный эффект, если этим злоупотреблять. Витамины в большом количестве тоже причиняют вред. Понимание когда нужно использовать конкретный паттерн — это показатель зрелости специалиста.
Вот именно, это соглашение как писать код и в каждом языке своя идеология написания кода. То, что на ООП делается через классы, в ФП делается через коллбеки, замыкания и керринг. А в js через классы, коллбеки, замыкание и керринг.
Перенося паттерны из одной идеологии в другую они видоизменяются и часто даже называются иначе.
Использовать библиотеку для js поверх jvm — звучит хорошо!
Но ведь для этого есть все тот же nashorn и еще парочка других движков. Для использования js библиотек не нужно затягивать целую node.js экосистему в jvm.
А если все же по какой-либо причине нужно использовать библиотеку, которая работает только под node.js — лучше уже поднять node.js отдельно и настроить общение через какой-то канал связи (сокеты, вебсокеты, http, message queue). Но это уже пахнет проблемой в архитектуре.
В мире ООП одни подходы, описанные в статье, в функциональном мире — другие, а в js как получится =)
Вот к примеру в js любой callback — это реализация паттерна стратегия, хоть и выглядит совсем не так, но суть у них одна.
А система обработки событий — это ничто иное как chain of responsibility.
Да, бывает и такое. Все результат будет отличаться от того, в каких руках инструмент.
Один напишет абстрактную фабрику по созданию абстрактных фабрик для создания абстрактных молотков.
А другой напишет удобную расширяемую систему, с которой приятно работать.
Unity3D и Unreal Engine позиционируют себя как игровые движки. А вот Flash и AIR, позиционируются (позиционировалась) как платформа общего назначения, которая будет работать везде.
Да и если посмотреть по сторонам, то можно увидеть, что сообщество считает флеш мертвым. Вернее уже 5 лет как хочет, чтобы он умер. И как это не печально, все к тому идет.
Да, такие иногда встречается. Но по-моему, оригиналы всегда лучше; если и повторяются, то подают информацию немного по-разному. В наших переводах эта информация выглядит просто одинаково, порою одна и та же фраза и почему-то переводы всегда больше оригиналов по объему.
Переводчики по большей части не улавливают разницу в двух фразах и переводят одинаково.
Спасибо. Я его расценивал как игровой движок. Хотя, по факту, это же замена флешу, а флеш — это был более универсальный инструмент, чем игровой движок. Вы правы.
Это было очень сильное заявление. Оно очень точно описывает все программные продукты от IBM.
В java «хардкора» не меньше, чем в js, он просто другой =)
но обсуждение этого топика скатится в холивар)))
Как я писал ниже, есть настроения писать серьезные приложения на js с большими объемами логики (фактически заменить нативные приложения). Эти приложения должны быть Легкими в поддержке и Быстрыми в изучении.
Вот к примеру какая-нибудь программа для расчета бухгалтерии. Сейчас есть онлайн-решения, но они построены по принципу тонкого клиента. А ведь можно же сделать толстый клиент, который сможет работать оффлайн и не будет на каждый чих дергать бекэнд.
Объемы бизнес логики в бухгалтерском приложении неимоверные. А при текущем положении дел такое приложение будет состоять из сырых хеш таблиц и функций, которые с ними работают.
Но в целом да, можно сказать: «не хочу в такой проект, я хочу что-то классное!»
Это облегчает жизнь, когда нужно поддерживать обратную совместимость. Появляется возможность безболезненно менять строение внутренних классов, главное, чтобы они соответствовали интерфейсу. Можно добавлять, удалять, изменять имплементации (они внутренние и никто не может на них завязаться).
Пример тому в Java — EnumSet.
Позволяет создать множество из enum объектов. При необходимости, в метод, принимающий EnumSet можно передать мок или свою реализацию. Но вот залезть в этот «фреймворк» и каким-то образом изменить его стандартное поведение, не получится.
В зависимости от количества элементов в Enum, этот класс может выдать разные реализации, некоторые будут построены на битовой маске int, некоторые на битовой маске long, если 32 или 62 бита не хватит — можно использовать массив. Нужно будет создать множество из одного элемента — пожалуйста. Если тесты производительности покажут, что Конкретная имплементация для 2 элементов будет работать лучше, чем имплементация с битовой маской — можно добавить ее и просто обновив версию пользователь получит прирост производительности без каких либо изменений своего кода.
Класс из ES2015 (принято же так называть, а не ES6) действительно не столь хорош, каким бы мог бы быть. Я выше приводил пример языка, который был бы отличным путем развития.
Это лишь для демонстрации синтаксиса. Как видно, то, что вам не нравится в ES2015 в том же as3 реализовано так, как вам хотелось бы. Хотите — пишите в ES5, хотите пишите в виде ООП.
Т.к. это все же ES, никто не отменяет использование прототипов, можно уже существующим объектам подсунуть миксин.
Но! Почему-то миллионы леменгов хотят принести ООП и систему классов. Стоит посмотреть на старые библиотеки / фреймворки. Каждая из них вводит свой вариант создания Класса. jQuery, Backbone, Lodash, у них у всех свой путь к созданию эдакой системы типов. «Более современные» идут тем же путем.
Ответственные за развитие ES вводят классы. Может не все так хорошо с этим путем?
И ведь это все мы сейчас смотрим только с точки зрения веба (js для работы с DOM), тут и вправду можно обойтись ES5 и компонентным подходом к написанию кода.
Но кроме как для работы с DOM js используется еще и на бекенде (node.js | express.js). На js сейчас пишутся огромные веб-приложения с кучей бизнес логики (не только манипуляция с DOM). А еще игры пишут на js.
И вот для больших приложений и игр без объектной модели довольно тяжело будет обеспечивать поддержку.
Вот представим, что у нас есть Quake, написанный на js (Quake — это очень маленькое, по объемам логики, приложение). И у нас есть ошибка, конкретную точку, где она проявляется — мы знаем. Как найти все пути, которые приводят к этой точке кода?
Самолет — это механизм.
Птица — это живое существо.
Самолет и Птица может летать (летающий объект).
В небе можно увидеть Летающие объекты.
А на счет застоя, я не соглашусь. Когда все будут знать ответы на базовые вопросы, тогда произойдет качественный скачек развития всего ИТ мира.
Вот только чтобы знать ответы на все базовые вопросы, нужно очень много времени потратить. «Программирование — это не работа, это образ жизни».
Мой посыл был в том, что можно же взять такой синтаксис за основу и просто прикрутить к нему синтаксический сахар в виде стрелочных функций, асинхронных функций и генераторов.
Все js разработчики всегда плюются в сторону классов и типов, но при этом лучшие из них создают свою собственную систему классов / типов, а V8 под капотом типизирует создаваемые объекты.
Некоторые и вовсе собрались и создали TypeScript. Казалось бы крутая штука! Но как и все, что делается под эгидой Microsoft — сделано криво.
Дошло до того, что в ES2015 все же ввели классы, но не ввели типизацию (надеюсь, еще одумаются), теперь половина плюется, половина с радостью использует. Классы на самом деле хороши, но нету модификаторов доступа (public, private), которая иногда очень даже нужна. Нету полей класса, их можно объявить только через конструктор.
Почему все крутые чуваки в мире JS (ES) всегда стараются изобрести велосипед?
Вот уже много лет есть готовый язык, который основан на базе ES5, в котором есть Классы, Декораторы, Spread syntax, Поля классов, Модификаторы доступа, Интерфейсы. При этом язык позволяет создавать и использовать анонимные объекты и функции как в ES5, позволяет не описывать типы у параметров и возвращаемых значений, позволяет принимать любые значени (т.е. писать в ES5 стиле).
ActionScript3 — язык созданный на базе ES5, для Flash. Но сам синтаксис очень вкусный и без проблем подошел бы как путь развития синтаксиса ES.
У всего хорошего всего есть побочный эффект, если этим злоупотреблять. Витамины в большом количестве тоже причиняют вред. Понимание когда нужно использовать конкретный паттерн — это показатель зрелости специалиста.
А в js через классы, коллбеки, замыкание и керринг.Перенося паттерны из одной идеологии в другую они видоизменяются и часто даже называются иначе.
Но ведь для этого есть все тот же nashorn и еще парочка других движков. Для использования js библиотек не нужно затягивать целую node.js экосистему в jvm.
А если все же по какой-либо причине нужно использовать библиотеку, которая работает только под node.js — лучше уже поднять node.js отдельно и настроить общение через какой-то канал связи (сокеты, вебсокеты, http, message queue). Но это уже пахнет проблемой в архитектуре.
В мире ООП одни подходы, описанные в статье, в функциональном мире — другие, а в js как получится =)
Вот к примеру в js любой callback — это реализация паттерна стратегия, хоть и выглядит совсем не так, но суть у них одна.
А система обработки событий — это ничто иное как chain of responsibility.
Один напишет абстрактную фабрику по созданию абстрактных фабрик для создания абстрактных молотков.
А другой напишет удобную расширяемую систему, с которой приятно работать.
Да и если посмотреть по сторонам, то можно увидеть, что сообщество считает флеш мертвым. Вернее уже 5 лет как хочет, чтобы он умер. И как это не печально, все к тому идет.
Переводчики по большей части не улавливают разницу в двух фразах и переводят одинаково.