Комментарии 39
Я думаю завоюет. Вон какая птичка милая.
НЛО прилетело и опубликовало эту надпись здесь
Прежде всего события самодостаточны. Когда компонент вызывает событие, он не подозревает, получил ли кто-то его или нет. Это свойство позволяет разработчику рассматривать каждый компонент в отдельности, вместо того, чтобы помнить обо всех связях и рассуждать о растущей сложности приложения, как единого целого.
События — не панацея против растущей сложности. Когда нужно смоделировать более-менее сложное взаимодействие 2-х и более компонентов, общение через события может стать той ещё головной болью, и захочется старых-добрых вызовов методов объектов. С событиями код становится чище, а вот разработчику нужно помнить больше, чем если бы в коде было написано «classA.methodB», потому как под записью «this.trigger('someEvent', args)» все равно может предполагаться общение с конкретным компонентом, только теперь про это в коде не написано.
когда нужно между кучей объектов обмениваться сообщениями для упрощения запоминания используют менеджеры эвентов
Ну да, упростили. Было: вызовы нескольких методов, стало несколько событий + менеджер событий на группу объектов.
Мне нравятся события, это ближе к православному ООП, но, на мой взгляд, вопросы борьбы со сложностью события решают не так уж и хорошо, как это постулируется в статье.
Мне нравятся события, это ближе к православному ООП, но, на мой взгляд, вопросы борьбы со сложностью события решают не так уж и хорошо, как это постулируется в статье.
События ближе к ООП чем вызовы методов? Какую букву SOLID мне читать?
А вы читайте между «букв». :)
Могу посоветовать посмотреть в сторону smalltalk и более ранних наработок, а так же в сторону ANSI Common Lisp.
За аббревиатурой ООП скрыто слишком много смыслов, которыми её нагрузили в 90-ых и 2000-ых годах. Развитие объектно-ориентированного подхода не закончилось симулой и не останавливается на стандарте Java или какого-то другого языка. Понимание того, как удобнее работать с объектами, развивается, — появляются новые языки и концепции (взять тот же Go). На мой взгляд, общение с объектами с помощью событий или сообщений больше походит на реальный мир, чем вызовы методов, — это мое мнение. Может быть, через 10 лет какой-нибудь исследователь попытается описать современную ему конъюнктуру, и дополнит SOLID (или логично интегрирует) событийной концепцией. ;)
Могу посоветовать посмотреть в сторону smalltalk и более ранних наработок, а так же в сторону ANSI Common Lisp.
За аббревиатурой ООП скрыто слишком много смыслов, которыми её нагрузили в 90-ых и 2000-ых годах. Развитие объектно-ориентированного подхода не закончилось симулой и не останавливается на стандарте Java или какого-то другого языка. Понимание того, как удобнее работать с объектами, развивается, — появляются новые языки и концепции (взять тот же Go). На мой взгляд, общение с объектами с помощью событий или сообщений больше походит на реальный мир, чем вызовы методов, — это мое мнение. Может быть, через 10 лет какой-нибудь исследователь попытается описать современную ему конъюнктуру, и дополнит SOLID (или логично интегрирует) событийной концепцией. ;)
Мне кажется, это зависит целиком от паттерна, который используется в конкретной задаче. Например в стандартную иерархическую модель вполне укладываются и события, и вызовы методов. Но там вполне себе дерево, нет никаких сложных связей, события выглядят семантично и даже в некотором роде удобно. Берем штуку со связами посложнее — и сеть событий сразу делает ее нерасширяемой, усиливая связанность.
Так что идея экстраполировать какой-то подход на весь ООП мне лично кажется несколько надуманной. К православному ООП ближе не события и не методы, если уж на то пошло, а структурность и модульность.
Так что идея экстраполировать какой-то подход на весь ООП мне лично кажется несколько надуманной. К православному ООП ближе не события и не методы, если уж на то пошло, а структурность и модульность.
Вот бы было бы больше статей на Хабре по архитектурным вопросам.
только теперь про это в коде не написано.
Так не подойдёт?
this.trigger('classA.methodB', args);
нетуда
Уже знаю, куда применить :)
Twitter изобрел pub/sub и назвал его flight. Ну пощупаем, но вообще согласен c Goder, общение через глобальные события просто меняет кашу методов на кашу событий, и кроме того будет больше кода и меньше жизненных радостей типа быстрого перехода на определение. Вообще не понимаю мотивацию делать все через искусственные события, в ООП вызов метода — это же и есть событие, посланное экземпляру.
Для скромного количества компонент впрочем вполне подойдет, хотя не вижу особой разницы между flight и обычным паб/сабом
Для скромного количества компонент впрочем вполне подойдет, хотя не вижу особой разницы между flight и обычным паб/сабом
это новая мода на MOVE отравляет мозги.
Вообще не понимаю мотивацию делать все через искусственные события, в ООП вызов метода — это же и есть событие, посланное экземпляру.
Вечное противостояние «модульное vs монолитное». Смысл в том, что вашим кодом могут захотеть воспользоваться после вас. Отреагировать на что-то, о чем вы даже не подозреваете. Скажем, мы пишем файловую систему. Тогда у нас есть:
fileSystem.changed(file)или
file.fire("changed", …)Если после нас кто-то захочет написать нотификатор, во втором случае он подпишется на событие и покажет свой гроул. В первом случае — ему придется влезть в наш код и дописать:
fileSystem.changed(file); notifier.changed(file)На закуску мы из коробки получаем «вытесняющую многозадачность» на уровне приложения. Windows этот шаг, например, сделала 30 лет назад.
Это же JS, что мешает взять и сделать манки патч если требуется?
А такой подход через события только добавляет проблем в отладчике и повышает общий градус непонимаемости происходящего на странице.
Второй пример более подходящ, но посмотрите сами — он же просто меннее гибок. С методами вы можете послать одно и то же сообщение каждому отдельному экземпляру — на уровне языка. С событиями у вас одно жирное событие нв все экземпляры какого то класса. А что если вам в обработчике понадобится отличать экзкмпляры один от другого и логика будет зависеть от состояния обьекта? Вам придется лепить колбасу if-elseif-elseif-then. И восторг вдруг сразу куда то исчезает.
А такой подход через события только добавляет проблем в отладчике и повышает общий градус непонимаемости происходящего на странице.
Второй пример более подходящ, но посмотрите сами — он же просто меннее гибок. С методами вы можете послать одно и то же сообщение каждому отдельному экземпляру — на уровне языка. С событиями у вас одно жирное событие нв все экземпляры какого то класса. А что если вам в обработчике понадобится отличать экзкмпляры один от другого и логика будет зависеть от состояния обьекта? Вам придется лепить колбасу if-elseif-elseif-then. И восторг вдруг сразу куда то исчезает.
Вам придется лепить колбасу if-elseif-elseif-thenМне не придется, я понимаю, как работают сообщения. В одно жирное событие мне никто не помешает передать свой
id.А если я не хочу, чтобы мои экземпляры отличались — значит и потребителю это не нужно. Инкапсуляция.
Оконный менеджер Windows, сюрприз, понимает, какое окно ему сообщило о желании свернуться. Сделано это в точности так, как во Flight.
> Сможет ли Flight завоевать такую же популярность у разработчиков, как и bootstrap? Время покажет!
Те кто прикипели к bootstrap (а их не мало), уже предрасположены к использованию новых фреймворков твиттера, так что думаю популярностью не будет обделен данный фреймворк, хотя бы попробовать его возьмутся многие.
Те кто прикипели к bootstrap (а их не мало), уже предрасположены к использованию новых фреймворков твиттера, так что думаю популярностью не будет обделен данный фреймворк, хотя бы попробовать его возьмутся многие.
Неужели только мне кажется что слово «легкий» как бы не совсем применимо к станичнике практически без дизайна, посетителю которой придется загрузить 143кб .css файлов, 366кб включаемых яваскриптов сразу и потом еще подгрузить около 100кб подгружаемых? :)
И для чего это все? Чтобы восторженным, но безответственным сайтописателям было удобнее отследить еще парочку событий? :)
И для чего это все? Чтобы восторженным, но безответственным сайтописателям было удобнее отследить еще парочку событий? :)
Думаю это скорее решение для сложных приложений. А там размер собственных скриптов не сопоставим с размером фреймворка.
Откройте для себя CDN. Если бы это сделал Василий Пупкин на коленке — вы были бы правы. Для библиотеки Flight из твиттера, количество загружаемого кода на нормально написанном постороннем сайте в 99% случаев будет 0Б. Кэш, знаете ли.
кэш непредсказуем знаете ли :) И рассчитывать что в 99% процентах случаев что-то там закешируется это тоже по-моему безответственность. И даже если закешируется, то как быть с посещением странички в первый раз? а с мобильника? а с какого-нибудь зверского тарифа в роуминге?
PS среднестатистический Василий, которых кодит руками, а не подключением библиотек, подобную функциональность сделает в коде весом 50кб. А чуть более возвышающийся над средним уровнем — 20кб и оно будет работать неотличимо от. В 99% случаев.
PS среднестатистический Василий, которых кодит руками, а не подключением библиотек, подобную функциональность сделает в коде весом 50кб. А чуть более возвышающийся над средним уровнем — 20кб и оно будет работать неотличимо от. В 99% случаев.
Требуемый конкретным приложением функционал jQuery тоже легко написать руками. Bootstrap тянусь за собой полностью — тоже не самое легковесное решение. А уж если оконный менеджер переписать под свое разрешение монитора, то можно от кучи малочитаемых if-then-else избавиться.
CDN придумали для того, чтобы выковывать спицы и не вытачивать из куска мрамора руль каждый раз, когда вам захочется прокатиться на велосипеде. Кроме того, эта библиотека не перестанет работать, когда все браузеры договорятся об особенной реализации пока нереализованного. А Вася к тому моменту уже три раза работу сменит.
CDN придумали для того, чтобы выковывать спицы и не вытачивать из куска мрамора руль каждый раз, когда вам захочется прокатиться на велосипеде. Кроме того, эта библиотека не перестанет работать, когда все браузеры договорятся об особенной реализации пока нереализованного. А Вася к тому моменту уже три раза работу сменит.
Вот насчет смен реализации и Васи на третьей работе согласен на 100%… Но это обычно решается вдумчивым упрощением и глубокими размышлениями на тему «а нужно ли мне это? а вот это?». А все что просто, обычно работает вне зависимости от текущего номера Васи и браузера.
Васи на третьей работеНа четвертой :-)
Я думаю, существует некоторая грань, до которой не имеет смысла изобретать свои велосипеды. Нельзя начинать каждый проект с написания своей собственной операционной системы. Я полагаю, что с учетом CDN и пропускной способности современных каналов предложенное решение — годится. Вы полагаете, что нет.
ОК, я сэкономлю на Васе и куплю себе мороженое.
даже 1мб скриптов сейчас не является проблемай, даже часто с мобильника ибо 3g быстр.
И спростите а почему вы должны писть одно и тоже приложение для мобильника и десктопа? Мне всегда казалось это бредом, и этот респонсив дизайн тоже, и бо реально тянется много лишнего если у вас все универсально для 2048 и 360 пикселей в ширину. Так что не думаю что вы правильно пыслите, тем более не забываем про gzip и кеш надежное решение тоже! Поверьте если 1-3% сайта будут имет ьпроблемы из-за отключенного кеша и прочего, я им могу спокойно сказать «до свидания».
Чтобы принимать решение об эффективности написанно приложения и скорости его работы и количества кода, надо для начало провести тестирование в реальных условиях, а не просто говорить что абстрактные 300кб — это много.
Я вот частенько на работе вставляю разработчикам которые начинают оптимизировать css js html глупыми способами типо: «делать короткие названия классов», «сжимать код делая его менее читаемым», «создание спрайтов руками, без реальной необходимости в этом» Все это и многое другое уже делается автоматически на сервере, сжатие скрипта gzip'ом и кеш дают очень хороший результат
И спростите а почему вы должны писть одно и тоже приложение для мобильника и десктопа? Мне всегда казалось это бредом, и этот респонсив дизайн тоже, и бо реально тянется много лишнего если у вас все универсально для 2048 и 360 пикселей в ширину. Так что не думаю что вы правильно пыслите, тем более не забываем про gzip и кеш надежное решение тоже! Поверьте если 1-3% сайта будут имет ьпроблемы из-за отключенного кеша и прочего, я им могу спокойно сказать «до свидания».
Чтобы принимать решение об эффективности написанно приложения и скорости его работы и количества кода, надо для начало провести тестирование в реальных условиях, а не просто говорить что абстрактные 300кб — это много.
Я вот частенько на работе вставляю разработчикам которые начинают оптимизировать css js html глупыми способами типо: «делать короткие названия классов», «сжимать код делая его менее читаемым», «создание спрайтов руками, без реальной необходимости в этом» Все это и многое другое уже делается автоматически на сервере, сжатие скрипта gzip'ом и кеш дают очень хороший результат
Я не понимаю, зачем мне это может быть нужно при наличии backbone и knockout.
Я не видел фреймворков, на которых сложно сделать hello world. Пара тысяч строк логики и выживают единицы.
Я не видел фреймворков, на которых сложно сделать hello world. Пара тысяч строк логики и выживают единицы.
Все очень просто — выбирайте что по душе и пользуйтесь.
Испытываю ту же проблему, надо сделать что то вроде todomvc но только с более сложной логикой.
НЛО прилетело и опубликовало эту надпись здесь
Осталось только заиметь список готовых компонентов, тогда, видимо, это и будет фреймворк.
А пока – ничего нового из того, что не делает jQuery UI, Backbone или любая другая нормальная архитектура на js.
А пока – ничего нового из того, что не делает jQuery UI, Backbone или любая другая нормальная архитектура на js.
Интересно, чем он лучше AngularJS? И почему навязывание своего подхода плохо?
Кстати, тем кто использует rails могу предложить адаптацию flight-for-rails (https://github.com/rezwyi/flight-for-rails). В своих проектах использую, полет нормальный :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flight — новый js-фреймворк от Twitter