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