Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
Автор в эпоху джекверей создал деревянный велосипед и описал его как ядерный реактор.
да-да, я че то видел в статье по поводу джекверей, но мой маленький мозг не может понять почему это нереализуемо на них.
да-да, я че то видел в статье по поводу джекверей, но мой маленький мозг не может понять почему это нереализуемо на них.
не реализуемо что?
«деревянный велосипед» изобрели светила современного программирования, те самые GoF, вы можете погуглить что такое «шаблоны проектирования» (да ту же вики почитать).
вы не дочитали всего-навсего реализацию на JS с очень незначительными вариациями от классики, в отличие от множества других примеров декоратора когда «работоспособность остается», а профит от подхода много меньше.
вы не дочитали всего-навсего реализацию на JS с очень незначительными вариациями от классики, в отличие от множества других примеров декоратора когда «работоспособность остается», а профит от подхода много меньше.
Если пользоваться одними JQuery, мозг не только станет маленьким, но еще и полностью гладким
Если пользоваться одними шаблонами, мозг не только станет маленьким, но еще и полностью гладким.
Ну и за что минусим?
Я тут, если что, истину пытаюсь донести. Шаблоны ни разу не панацея, от некоторых вообще стоит держаться подальше.
Ну и еще один гвоздь: решая задачу, отталкиваться надо именно от нее, а не от манящего решения в виде шаблона. Часто бывает, что шаблоны применяют без повода (как и ООП), а потом в коде черт ногу сломит.
Это как не видеть лес за деревьями, то бишь, конечно, настоящее решение за шаблонами.
Я тут, если что, истину пытаюсь донести. Шаблоны ни разу не панацея, от некоторых вообще стоит держаться подальше.
Ну и еще один гвоздь: решая задачу, отталкиваться надо именно от нее, а не от манящего решения в виде шаблона. Часто бывает, что шаблоны применяют без повода (как и ООП), а потом в коде черт ногу сломит.
Это как не видеть лес за деревьями, то бишь, конечно, настоящее решение за шаблонами.
Шаблоны это лишь способ организации архитектуры, никто не мешает тебе реализовывать идею именно так, как ее нужно реализовать наилучшим образом; что шаблоны и ООП отлично структурируют код и упрощают его повторное использование (если конечно уметь правильно реализовывать и ООП, и шаблоны).
слово «что» было лишним :)
>если конечно уметь правильно реализовывать и ООП, и шаблоны
О. А что есть «правильно»? И как реализовывать ООП?
О. А что есть «правильно»? И как реализовывать ООП?
Правильно реализовывать шаблоны — значит реализовывать их именно так, как говорится в спецификации к шаблону, это же очевидно)
На тему ООП в javascript существует куча статей, в частности msdn.microsoft.com/ru-ru/magazine/cc163419.aspx
На тему ООП в javascript существует куча статей, в частности msdn.microsoft.com/ru-ru/magazine/cc163419.aspx
>Правильно реализовывать шаблоны — значит реализовывать их именно так, как говорится в спецификации к шаблону, это же очевидно)
Я не спрашивал про шаблоны. Я спрашивал про «правильность» и «реализацию ООП» (очевидно «правильную»).
Я не спрашивал про шаблоны. Я спрашивал про «правильность» и «реализацию ООП» (очевидно «правильную»).
Вы в чем-то нашли не«правильность»?
Я ответил и про шаблоны, и про ООП. Зачем холиварить? :)
я подумал, что я что-то пропустил
Вы не ответили про «правильность». Либо дайте мне его определение, либо не применяйте его в споре.
Не вижу смысла в очевидных вещах, ну да ладно. Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
>Не вижу смысла в очевидных вещах, ну да ладно.
Отличный демагогический прием.
>Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
Что такое «архитектура ООП»? Как ее применить к алгоритму? Причем тут синтаксис?
Отличный демагогический прием.
>Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
Что такое «архитектура ООП»? Как ее применить к алгоритму? Причем тут синтаксис?
> Что такое «архитектура ООП»
ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
> Как ее применить к алгоритму
С помощью мозга, видимо
> Причем тут синтаксис
Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
> Как ее применить к алгоритму
С помощью мозга, видимо
> Причем тут синтаксис
Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
>> Что такое «архитектура ООП»
>ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Расскажите своими словами про «архтитектуру ООП». У вас это хорошо получается. Узнаю много нового.
>> Как ее применить к алгоритму
>С помощью мозга, видимо
А конструктивно можете объяснить?
>Синтаксис при среде реализации алгоритма.
ЛОЛШТО?
>ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Расскажите своими словами про «архтитектуру ООП». У вас это хорошо получается. Узнаю много нового.
>> Как ее применить к алгоритму
>С помощью мозга, видимо
А конструктивно можете объяснить?
>Синтаксис при среде реализации алгоритма.
ЛОЛШТО?
Выучи сначала, что такое «архитектура» и какое отношение это слово имеет к программированию.
> С помощью мозга, видимо
У тебя он гладкий, что и требовалось показать.
> Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
Синтаксис в JS и C++ довольно похожий (Си-подобный же), зато разная модель памяти (в JS с выделением машинной памяти вообще не сталкиваешься), хотя модель вычислений примерно одна и та же (вычисление в окружении, но оно тоже по-разному выглядит, ибо в JS есть функции первого класса и замыкания).
Короче, учи матчасть, а то я тут уже несколько раз под стол падал от твоих сентенций.
> С помощью мозга, видимо
У тебя он гладкий, что и требовалось показать.
> Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
Синтаксис в JS и C++ довольно похожий (Си-подобный же), зато разная модель памяти (в JS с выделением машинной памяти вообще не сталкиваешься), хотя модель вычислений примерно одна и та же (вычисление в окружении, но оно тоже по-разному выглядит, ибо в JS есть функции первого класса и замыкания).
Короче, учи матчасть, а то я тут уже несколько раз под стол падал от твоих сентенций.
синтаксис, я так понимаю, применялся в значении «реализация на конкретном языке». сходства у любых языков имеются.
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете
> синтаксис, я так понимаю, применялся в значении «реализация на конкретном языке».
Интересное значение, раньше не встречал. Я пользуюсь другим, и всем рекомендую: синтаксис это набор правил, определяющих множество комбинаций символов, которые считаются синтаксически корректными программами какого-то языка.
> сходства у любых языков имеются.
Это только в теории. На практике же, дай вам программку на Haskell, вы ее не осилите без должной подготовки — слишком мало общего с JS на первый, второй и n-ый взгляд. :) (на Haskell пишут совсем не так, как на JS — «культура» сказывается)
> я так и не понял, почему у ap3rus'а мозг гладкий?
Потому что он, как попугай, повторяет чьи-то истины, о которых не знает сам.
> Вы доступно, с толком, с расстановкой это аргументируете
Я уже аргументировал, толку ноль, зато минусов нахватался. :) За что? За то, что тут кучка идиотов возводит шоблончеги в божество какое-то, а я посмел его осквернить.
А вообще-то не надо признавать, чей мозг мелкий и гладкий, читайте книжки просто. ;-)
Интересное значение, раньше не встречал. Я пользуюсь другим, и всем рекомендую: синтаксис это набор правил, определяющих множество комбинаций символов, которые считаются синтаксически корректными программами какого-то языка.
> сходства у любых языков имеются.
Это только в теории. На практике же, дай вам программку на Haskell, вы ее не осилите без должной подготовки — слишком мало общего с JS на первый, второй и n-ый взгляд. :) (на Haskell пишут совсем не так, как на JS — «культура» сказывается)
> я так и не понял, почему у ap3rus'а мозг гладкий?
Потому что он, как попугай, повторяет чьи-то истины, о которых не знает сам.
> Вы доступно, с толком, с расстановкой это аргументируете
Я уже аргументировал, толку ноль, зато минусов нахватался. :) За что? За то, что тут кучка идиотов возводит шоблончеги в божество какое-то, а я посмел его осквернить.
А вообще-то не надо признавать, чей мозг мелкий и гладкий, читайте книжки просто. ;-)
> Интересное значение, раньше не встречал.
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
> «Синтаксис в JS и C++ довольно похожий»
Я не говорил, что он разный, я сказал что реализация ООП в javascript и в C++ довольно отличается, в Javascript нет наследования, но есть прототипирование, в javascript любой объект или функция является одновременно и объектом, проектирование ООП модели следует делать полагаясь на эти различия.
Я не говорил, что он разный, я сказал что реализация ООП в javascript и в C++ довольно отличается, в Javascript нет наследования, но есть прототипирование, в javascript любой объект или функция является одновременно и объектом, проектирование ООП модели следует делать полагаясь на эти различия.
> проектирование ООП модели следует делать полагаясь на эти различия
Модели чего? Реального мира, наверное. А где вы в реальном мире видели «декораторов»? :) (нет, ну конечно же, можно придумать физическую аналогию; я тут придираюсь к слову «модель» просто)
Но вы съехали куда-то не туда. ООП (абстракция данных, если хотите) с шаблонами (костылями, если угодно) не являются ответом на все вопросы! Надо знать, когда ООП применимо, а когда нет, а в распеаренных книжках Буча и прочих «светил» об этом ни слова.
Модели чего? Реального мира, наверное. А где вы в реальном мире видели «декораторов»? :) (нет, ну конечно же, можно придумать физическую аналогию; я тут придираюсь к слову «модель» просто)
Но вы съехали куда-то не туда. ООП (абстракция данных, если хотите) с шаблонами (костылями, если угодно) не являются ответом на все вопросы! Надо знать, когда ООП применимо, а когда нет, а в распеаренных книжках Буча и прочих «светил» об этом ни слова.
> Модели чего? Реального мира, наверное.
Такое чувство, будто я разговариваю с учителем литературы)
> Надо знать, когда ООП применимо, а когда нет… а в распеаренных книжках Буча
С учителем я погорячился ;)
Я как раз об этом и говорю, нужно использовать свой мозг, перед тем, как пытаться что-либо применить. А читать книжки нужно, хотя бы для того, чтобы знать что такое ООП.
Такое чувство, будто я разговариваю с учителем литературы)
> Надо знать, когда ООП применимо, а когда нет… а в распеаренных книжках Буча
С учителем я погорячился ;)
Я как раз об этом и говорю, нужно использовать свой мозг, перед тем, как пытаться что-либо применить. А читать книжки нужно, хотя бы для того, чтобы знать что такое ООП.
а кто говорил, что это панацея?
Ну а кто применяет шаблоны там, где не надо?
PS я определяю рамки применимости шаблонов как очень скромные: там, где язык не позволяет выразить какую-то мысль явно, приходится использовать шаблоны, дабы обойти ограничения. Примеры: функции первого класса и замыкания.
PS я определяю рамки применимости шаблонов как очень скромные: там, где язык не позволяет выразить какую-то мысль явно, приходится использовать шаблоны, дабы обойти ограничения. Примеры: функции первого класса и замыкания.
В вашем же случае: отсутствие первоклассных сообщений (и следовательно, возможности делегировать сообщение другому объекту) заставляет юзать какой-то там «декоратор» (название-то какое!).
Вообще-то делегировать в JS можно посредством прототипов, надо подумать.
Но вы же не в ту степь ломанулись сразу же: абстрагировать данные там, где нужно абстрагировать алгоритм!
А все отчего? От того, что я писал выше: отталкиваться надо от проблемы, а не от шаблона.
Вообще-то делегировать в JS можно посредством прототипов, надо подумать.
Но вы же не в ту степь ломанулись сразу же: абстрагировать данные там, где нужно абстрагировать алгоритм!
А все отчего? От того, что я писал выше: отталкиваться надо от проблемы, а не от шаблона.
не буду утверждать, что данный пример — эталон js+декоратор, но вполне себе хороший пример. сможете привести получше — скажу спасибо
Дык я ж не о том совсем! Я исключительно о применении шаблона не по назначению.
Что же касается примеров шаблона — зачем они? Мне кажется, если у человека возникает необходимость в делегировании в JS — то он берет и использует прототипы.
Что же касается примеров шаблона — зачем они? Мне кажется, если у человека возникает необходимость в делегировании в JS — то он берет и использует прототипы.
видимо, я чего-то не понимаю.
делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект. при этом, сам он не расширяет функциональность «вложенного» метода. если он что-то делает, а потом вызывает — это декоратор.
можно этот же пример сделать с помощью «не особо делегирования», нам понадобятся следующие классы: BaseScroll_plus_Buttons, BaseScroll_plus_PageNum, BaseScroll_plus_Buttons_plus_PageNum — и еще столько же для AnimScroll.
А если мы не хотим иметь шесть классов, то можно сделать метод компоненты и декораторы :)
делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект. при этом, сам он не расширяет функциональность «вложенного» метода. если он что-то делает, а потом вызывает — это декоратор.
можно этот же пример сделать с помощью «не особо делегирования», нам понадобятся следующие классы: BaseScroll_plus_Buttons, BaseScroll_plus_PageNum, BaseScroll_plus_Buttons_plus_PageNum — и еще столько же для AnimScroll.
А если мы не хотим иметь шесть классов, то можно сделать метод компоненты и декораторы :)
> делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект.
Да, но по ходу действия он может все что хочет делать с сообщением. ;) Делегирование и наследование — это две стороны одной монеты.
Кстати, объект-получатель может быть неинкапсулированным, а каким-нибудь глобальным. Достаточно, чтобы он был замкнут относительно объекта-прокси.
Да, но по ходу действия он может все что хочет делать с сообщением. ;) Делегирование и наследование — это две стороны одной монеты.
Кстати, объект-получатель может быть неинкапсулированным, а каким-нибудь глобальным. Достаточно, чтобы он был замкнут относительно объекта-прокси.
есть несколько, уже упомянутых, понятий: делегирование, декорирование, наследование. они, правда, в разных весовых категориях, но можно взять абсолютно любой код, выдрать из него ± любой кусок и сказать: «здесь употребляется (делегирование|декорирование|наследование)».
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
Это не понятия, это каша.
Понятия — это сообщение, и передача сообщения которое тоже есть сообщение. :)
> передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
Нет. Допустим, что «Класс» это глобальный объект, которому мы можем отправить сообщение, чтобы определить новый класс. Смотрим Smalltalk и удивляемся.
Понятия — это сообщение, и передача сообщения которое тоже есть сообщение. :)
> передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
Нет. Допустим, что «Класс» это глобальный объект, которому мы можем отправить сообщение, чтобы определить новый класс. Смотрим Smalltalk и удивляемся.
да, единственный способ заставить объект работать — вызвать его метод (сообщение передать). когда мы говорим классу: «new» — нам возвращается новый объект. чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
> да, единственный способ заставить объект работать — вызвать его метод (сообщение передать)
Передача сообщений — более общее понятие. Бывают синхронные, асинхронные, бывают с продолжением, бывают с замыканием и тп. Передача сообщений это модель вычисления, по мощности эквивалентная машине Тьюринга и лямбда-исчислению.
> чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
Понятия «наследование», «полиморфизм», «делегирование» и пр. в мейнстримовых языках являются кашей из-за отсутствия их четкого формального определения. Это самое определение должно схватить самую *суть*, а не сиюминутные прихоти «орхетекторов» языка.
И напоследок, пару пойнтов.
В настоящем ООП всякие костыли вроде таких любимых народом шаблончегов просто не нужны (в них не возникает необходимости, так то!).
Шаблоны проектирования являются неудачными абстракциями из-за того, что не уменьшают количество писанины, не позволяют строить на их основе другие абстракции, и только худо-бедно позволяют программисту размышлять над кодом.
Dixi.
Передача сообщений — более общее понятие. Бывают синхронные, асинхронные, бывают с продолжением, бывают с замыканием и тп. Передача сообщений это модель вычисления, по мощности эквивалентная машине Тьюринга и лямбда-исчислению.
> чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
Понятия «наследование», «полиморфизм», «делегирование» и пр. в мейнстримовых языках являются кашей из-за отсутствия их четкого формального определения. Это самое определение должно схватить самую *суть*, а не сиюминутные прихоти «орхетекторов» языка.
И напоследок, пару пойнтов.
В настоящем ООП всякие костыли вроде таких любимых народом шаблончегов просто не нужны (в них не возникает необходимости, так то!).
Шаблоны проектирования являются неудачными абстракциями из-за того, что не уменьшают количество писанины, не позволяют строить на их основе другие абстракции, и только худо-бедно позволяют программисту размышлять над кодом.
Dixi.
/me как бы вторит К.О.: работа выполнена, конечно же, из академического интереса?
изначально, да, был чисто академический интерес. сначала посмотрел примеры, книгу почитал, написал на js абстрактное решение. потом начал думать о хоть каком-нибудь примере из реальной жизни, и додумался до вот такой штучки.
и вот когда я до неё додумался :) понял профитность реализации «как написано», а не как умею.
и вот когда я до неё додумался :) понял профитность реализации «как написано», а не как умею.
Статья, что называется в руку. Третий день думаю как реализовать взаимодействие между «классами». Спасибо и низкий поклон! :)
Вы уж меня простите, я не стал полнсотью читать статью (потому что я не люблю кодить на жс без фремйворка).
Я не знаком с паттернами, но не так давно я делал один сайт, и у меня в голове зародилось кое-что похожее.
Но комментарий не об этом. Хочу написать, где вообще в JS может пригодится подобное.
Дано: сайт, на нём дизайнер родил аж три галереи. Функционал похожий: область где показывается текущая картинка и область filmstripa. Но дизайн везде разный, филмстрип где вертикальный, где горизонтальный, анимации разные, где-то нужно оверлеить дополнительную информацию.
Тогда я написал базовый класс (используя мутулсы), управляющий всем этим безобразием, а для каждой конкретной галереи он доопределялся своими классами: добавлялись какие-то действия на события, уточнялись настройки. Вышло чертовски прикольно и кратко (сильно короче листинга в посте).
Я не знаком с паттернами, но не так давно я делал один сайт, и у меня в голове зародилось кое-что похожее.
Но комментарий не об этом. Хочу написать, где вообще в JS может пригодится подобное.
Дано: сайт, на нём дизайнер родил аж три галереи. Функционал похожий: область где показывается текущая картинка и область filmstripa. Но дизайн везде разный, филмстрип где вертикальный, где горизонтальный, анимации разные, где-то нужно оверлеить дополнительную информацию.
Тогда я написал базовый класс (используя мутулсы), управляющий всем этим безобразием, а для каждой конкретной галереи он доопределялся своими классами: добавлялись какие-то действия на события, уточнялись настройки. Вышло чертовски прикольно и кратко (сильно короче листинга в посте).
Хорошо, интересно.
Вот только как это можно применить, зачем это?
Вот только как это можно применить, зачем это?
Прямо над вашим комментарием я написал хороший пример того, как можно применить что-то подобное.
И думаю это не единственная ситуация.
И думаю это не единственная ситуация.
не хотелось бы отвечать «где угодно» или копипастить, попробую «от души» ответить, голосом сердца :)
обычно, приступая к написанию чего-либо, мы изучаем что нам надо сделать и берем в рассчет только то, что от нас хотят. мы готовы к переделкам очень относительно, но пока наше творение находится «внутри функции», или там в объекте, то чтобы что-то переделать, нам надо или положиться на удачу, или изучить функционал целиком. надо переделать второй раз — снова или положиться на удачу, или изучить функционал целиком.
что бы то ни было: калькуляторы, фотогалереи, система сообщений между пользователями на сайте — корзина отдельно, яйца отдельно :)
только я не призываю юзать это везде. абсолютно не призываю. каждую задачу можно решить бесконечным числом способов и нету какого-то универсального.
калькулятор считает размер скидки. есть 5 критериев. их можно взять и написать один за другим. надо выкинуть 3й и добавить новый — изучаем всю логику и режем кусочки, или не лезем в логику рассчетов, а удаляем в конструкторе подключение 3-го и пишем еще один. конечно, не всегда можно найти 5 обособленных критериев.
фотогалерея уже нашлась в комментах, см. выше.
система сообщений между пользователями на сайте может отображать кол-во новых сообщений в статус баре, и когда понадобится добавить алерт о новом сообщении, мы сможем сделать это быстро, а когда понадобится его удалить, не будет никаких сомнений в работоспособности системы. хотя, имхо, тут лучше наблюдатель задействовать :)
повторюсь, я не призываю юзать декоратор везде, а только там, где это действительно профитно.
обычно, приступая к написанию чего-либо, мы изучаем что нам надо сделать и берем в рассчет только то, что от нас хотят. мы готовы к переделкам очень относительно, но пока наше творение находится «внутри функции», или там в объекте, то чтобы что-то переделать, нам надо или положиться на удачу, или изучить функционал целиком. надо переделать второй раз — снова или положиться на удачу, или изучить функционал целиком.
что бы то ни было: калькуляторы, фотогалереи, система сообщений между пользователями на сайте — корзина отдельно, яйца отдельно :)
только я не призываю юзать это везде. абсолютно не призываю. каждую задачу можно решить бесконечным числом способов и нету какого-то универсального.
калькулятор считает размер скидки. есть 5 критериев. их можно взять и написать один за другим. надо выкинуть 3й и добавить новый — изучаем всю логику и режем кусочки, или не лезем в логику рассчетов, а удаляем в конструкторе подключение 3-го и пишем еще один. конечно, не всегда можно найти 5 обособленных критериев.
фотогалерея уже нашлась в комментах, см. выше.
система сообщений между пользователями на сайте может отображать кол-во новых сообщений в статус баре, и когда понадобится добавить алерт о новом сообщении, мы сможем сделать это быстро, а когда понадобится его удалить, не будет никаких сомнений в работоспособности системы. хотя, имхо, тут лучше наблюдатель задействовать :)
повторюсь, я не призываю юзать декоратор везде, а только там, где это действительно профитно.
К сожалению я не знаю js достаточно хорошо, поэтому хочу спросить — если в нем какой-нибудь аналог системы перехвата несуществующих функций объекта, как например метод __call() в пхп или класс Proxy в ас3?
Если есть то по идее можно было бы с помощью него улучшить абстрактный декоратор, реализовав в нем такую систему вместо перечисления функций декорируемого объекта
Если есть то по идее можно было бы с помощью него улучшить абстрактный декоратор, реализовав в нем такую систему вместо перечисления функций декорируемого объекта
на сколько я знаю, нету.
можно конечно exception-ы хватать и как-то обрабатывать, но это тот еще изврат :)
можно конечно exception-ы хватать и как-то обрабатывать, но это тот еще изврат :)
именно перехватывать несуществующие методы нельзя, только если с помощью try/catch, но это или try/catch при каждом вызове каждого метода (полный бред), или велосипед ввиде отдельной функции, которой передаются имя метода и аргументы, и уже она проверяет typeof(this[methodName]), но тоже красотой не блещет.
можно вот такой велосипед придумать, но следует ли им пользоваться — большой вопрос…
… но я бы лучше перечислял методы, ничего зазорного я в этом не вижу
можно вот такой велосипед придумать, но следует ли им пользоваться — большой вопрос…
function Component() {
this.fn1 = function(val) { alert("Component > fn1 " + val); };
this.fn2 = function(val) { alert("Component > fn2 " + val); };
}
function IDecorator() {
var dublicate = this;
var component;
this.setComponent = function(val) {
component = val;
for (var key in val) {
if (typeof(val[key])=="function") {
addMethod(key, val[key]);
}
}
};
this.getComponent = function() {
return component;
};
this.applyComponentMethod = function(name, argsArray) {
if (typeof(component[name])=="function") {
component[name].apply(dublicate, argsArray || []);
}
};
function addMethod(name, componentFn) {
dublicate[name] = function() {
return componentFn.apply(this, arguments || []);
}
}
}
function MyDecorator(component) {
var dublicate = this;
IDecorator.call(this);
this.setComponent(component);
this.fn1 = function(val) {
alert("MyDecorator > fn1 " + val);
dublicate.applyComponentMethod("fn1", [val]);
};
}
var c = new Component();
var d = new MyDecorator(c );
d.fn1(1); // "MyDecorator > fn1 1", "Component > fn1 1"
d.fn2(2); // "Component > fn2 2" и не думаю, что это хорошо
… но я бы лучше перечислял методы, ничего зазорного я в этом не вижу
я кое-чего у тебя не понял, ты написал метод
this.setComponent = function(val) {
component = val;
for (var key in val) {
if (typeof(val[key])==«function») {
addMethod(key, val[key]);
}
}
};
в нем ты задаешь component, а так же копируешь в IDecorator все методы component, но далее внутри
this.applyComponentMethod = function(name, argsArray) {
if (typeof(component[name])==«function») {
component[name].apply(dublicate, argsArray || []);
}
};
ты вызываешь метод именно объекта component, вопрос — зачем ты копируешь все методы к декоратору в IDecorator.setComponent? Нравится хранить мусор? =)
this.setComponent = function(val) {
component = val;
for (var key in val) {
if (typeof(val[key])==«function») {
addMethod(key, val[key]);
}
}
};
в нем ты задаешь component, а так же копируешь в IDecorator все методы component, но далее внутри
this.applyComponentMethod = function(name, argsArray) {
if (typeof(component[name])==«function») {
component[name].apply(dublicate, argsArray || []);
}
};
ты вызываешь метод именно объекта component, вопрос — зачем ты копируешь все методы к декоратору в IDecorator.setComponent? Нравится хранить мусор? =)
а, если их не копировать, то как потом в декораторе вызывать?
т.е. у компонента есть fn2, а у декоратора его нет — как вызвать fn2, обращаясь к декоратору и не проверяя каждый раз наличие fn2?
т.е. у компонента есть fn2, а у декоратора его нет — как вызвать fn2, обращаясь к декоратору и не проверяя каждый раз наличие fn2?
А действительно, с утра мозг сбуксовал)
Я хотел сказать другое, у IDecorator есть метод setComponent(val), который задает методы из объекта val, но если этот метод вызвать два раза для разных объектов, мусор скопится, можно было бы вставить проверку на то, что у IDecorator уже задан component, удалить все его методы, и только потом добавить новые методы. Либо же просто задание компонента перенести в конструктор IDecorator
Я хотел сказать другое, у IDecorator есть метод setComponent(val), который задает методы из объекта val, но если этот метод вызвать два раза для разных объектов, мусор скопится, можно было бы вставить проверку на то, что у IDecorator уже задан component, удалить все его методы, и только потом добавить новые методы. Либо же просто задание компонента перенести в конструктор IDecorator
d.fn2(2); // «Component > fn2 2» и не думаю, что это хорошо
ой, извиняюсь, поведение правильное
ой, извиняюсь, поведение правильное
упс, «есть ли» вместо «если» в первой строке.
Не уловил кошерности в примере.
На сколько я знаю этот шаблон нам нужен, когда у нас есть GOD-объект, а от него нам надо только А, Б и В.
Или, когда мы религиозные экстремисты и не приемлем иного фреймворка, нежели %framework_name%, и внешний компонент для скорости, оборачиваем в декоратор, который кошерен.
На сколько я знаю этот шаблон нам нужен, когда у нас есть GOD-объект, а от него нам надо только А, Б и В.
Или, когда мы религиозные экстремисты и не приемлем иного фреймворка, нежели %framework_name%, и внешний компонент для скорости, оборачиваем в декоратор, который кошерен.
GOD-объект? кошерность в использовании: нужны кнопки — добавляем кнопки, нужен индикатор страницы — добалвяем индикатор страницы.
[зануда]Подсветите плиз код, а то не очень удобно его читать[/зануда]
Плоховастенько (то бишь есть куда стремиться), ибо много кода.
Недавно (пару месяцев назад) писал анимацию на Flapjax, там была композиционность и то, на что вы тут тратите свое время, решалось просто и быстро.
Статья тут: chiaroscuro.yvision.kz/blog/9468.html
анимация с easeInOut:
> insertValueB(liftB(anim(em,-30.0,0.0), moveB(ev, 25, 250, easeInOut)), 'my-element', 'style', 'left');
без анимации (точнее, с мгновенной анимацией):
> function instantB(ev) {
> return startsWith(constantE(ev,1.0), 0.0);
> }
> insertValueB(liftB(anim(em,-30.0,0.0), instantB(ev), 'my-element', 'style', 'left');
Недавно (пару месяцев назад) писал анимацию на Flapjax, там была композиционность и то, на что вы тут тратите свое время, решалось просто и быстро.
Статья тут: chiaroscuro.yvision.kz/blog/9468.html
анимация с easeInOut:
> insertValueB(liftB(anim(em,-30.0,0.0), moveB(ev, 25, 250, easeInOut)), 'my-element', 'style', 'left');
без анимации (точнее, с мгновенной анимацией):
> function instantB(ev) {
> return startsWith(constantE(ev,1.0), 0.0);
> }
> insertValueB(liftB(anim(em,-30.0,0.0), instantB(ev), 'my-element', 'style', 'left');
Хех, и тут минусы. Вы бы разобрались, в чем дело-то сперва.
ОП просто-напросто нафигачил целое полотно из-за своего незнания, что есть такая штука, как абстракция алгоритма.
Зато шаблоны же, еба.
ОП просто-напросто нафигачил целое полотно из-за своего незнания, что есть такая штука, как абстракция алгоритма.
Зато шаблоны же, еба.
статья о шаблоне, а не о анимации.
Вы знаете, мое мнение — данный пример не пригоден за рамками академического интереса. Паттерны GOF довольно универсальны, но зацикливаться на них не стоит. В книге они реализованы для C++ и Smaltalk, но не стоит забывать об уникальной специфике каждого языка. Так например родились на свет паттерны J2EE. JS — клиентский язык, и в наших интересах писать крайне сжатый и быстрый код. Паттерны же в свою очередь смотрят в сторону повторного использования и простоты расширения, забывая об объеме кода — для серверных приложений это не столь принципиально. В этой книге имеется описание паттерна декоратор, но контекст применения совершенно иной, не dom-виджеты. Если честно — еще не читал, в ближайшее время прочитаю и вам советую: )
JS — клиентский язык
Не согласен. Реализация VM этого языка обычно встаивается в браузеры или Qt-программы, но называть целый язык клиенским — не надо. Язык вообще не может быть серверным/клиентским, только VM.
Вот вам пример серверной VM языка Javascript code.google.com/p/v8cgi/
А вот даже фреймворк, на основе небезызвестного MooTools для серверного Javascript raccoon.keetology.com/
Так что, по моему мнению, если не сейчас, то в скором будущем, реализации паттернов на Javascript станут нужными и будут использоватся на практике
Мы говорим о чем? О том коде, который клиент загружает себе каждый раз? (не думаем сейчас о кеше). Лично для меня JS прежде всего это клиентский язык. В данном топике речь идет о джаваскриптовом dom-скриптинге — не клиентские скрипты по вашему мнению??
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Вы не считайте, что до паттернов в JS никто еще не додумался, почитайте блог Дена Эдвардса например, все на свои места встанет.
Дело в том, что я сам когда стал въезжать в паттерны, стал их тутже реализовывать в JS, потом пришло чувство осознания, что я не самый хитрый.
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Вы не считайте, что до паттернов в JS никто еще не додумался, почитайте блог Дена Эдвардса например, все на свои места встанет.
Дело в том, что я сам когда стал въезжать в паттерны, стал их тутже реализовывать в JS, потом пришло чувство осознания, что я не самый хитрый.
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Именно об этом я и говорю. Вы сказали что
данный пример не пригоден за рамками академического интереса.
так как
JS — клиентский язык
Я дал вам пример того где данный пример пригоден к использованию. Автор сделал рабочий пример в среде браузера, но никто не мешает пользоватся этим кодом на стороне сервера.
Ерунда. Для js объём кода тоже давно не главное, всегда можно обфусцировать/запаковать, да и не бывает его слишком много в подавляющем большинстве случаев. Так что то что паттерны так увеличить код что даже обфусцированный он будет долго загружаться клиентом — полнейшая чушь. Хотя и область применения паттернов в JS мала, реально они требуются если пишете большой проект типа FCK Editor, в остальном только запутают код.
dom-виджет я выбрал, потому что визуальный пример с формочкой всегда понятнее, чем код, или описание кода.
книгу надо бы почитать, спасибо за ссылку, но зацикливаться на ней я тоже буду :)
краткость кода это хорошо, но его модифицируемость — гораздо лучше. быстрый код? не думаю, что эта штука будет тормозить. а реализовывать функционал, требующий максимальной скорости нужно, как бы это, «на языке», без архитектуры вообще… не знаю, как это по-человечески сказать :)
у меня тоже есть отступления от темы. Scroll, и Decorator — базовые классы, а не интерфейсы, из-за локальных переменных.
я не зацикливаюсь, просто под декоратором люди понимают все, что угодно: AOP, колбэки, перекидывание функции (именно функции, у которой return число возвращает) аргументом при инстанцировании декоратора. «но мне бы хотелось поделиться реализацией весьма близкой к GoF'у».
пример имеет, по сути, один JS-недостаток — объем кода. это плохо, но, имхо, еще не причина оставлять его в рамках академического интереса.
книгу надо бы почитать, спасибо за ссылку, но зацикливаться на ней я тоже буду :)
краткость кода это хорошо, но его модифицируемость — гораздо лучше. быстрый код? не думаю, что эта штука будет тормозить. а реализовывать функционал, требующий максимальной скорости нужно, как бы это, «на языке», без архитектуры вообще… не знаю, как это по-человечески сказать :)
у меня тоже есть отступления от темы. Scroll, и Decorator — базовые классы, а не интерфейсы, из-за локальных переменных.
я не зацикливаюсь, просто под декоратором люди понимают все, что угодно: AOP, колбэки, перекидывание функции (именно функции, у которой return число возвращает) аргументом при инстанцировании декоратора. «но мне бы хотелось поделиться реализацией весьма близкой к GoF'у».
пример имеет, по сути, один JS-недостаток — объем кода. это плохо, но, имхо, еще не причина оставлять его в рамках академического интереса.
после такого дисклэймера, напрашивается постскриптум:
за время реализации не пострадало ни одной функции :)
по оформлению:
я бы заподозрил очень малое количество читателей этого блога со встроенным в мозгу движком JS.
хотябы раскрашенный код был бы гораздо читабельнее.
а ещё лучше — сделать в духе документации по jquery:
код + рабочий пример
по теме:
а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс, расширив «интересные» методы и оставив ностальные в покое?
или это будет уже другой паттерн?
за время реализации не пострадало ни одной функции :)
по оформлению:
я бы заподозрил очень малое количество читателей этого блога со встроенным в мозгу движком JS.
хотябы раскрашенный код был бы гораздо читабельнее.
а ещё лучше — сделать в духе документации по jquery:
код + рабочий пример
по теме:
Все компоненты должны иметь одинаковый интерфейс,
а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс, расширив «интересные» методы и оставив ностальные в покое?
или это будет уже другой паттерн?
>а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс,
>расширив «интересные» методы и оставив ностальные в покое?
>или это будет уже другой паттерн?
Это будет слишком просто — пройти по списку функций и сделать такие же. Но у автора есть это в комментарии — только я не понял, почему это плохо.
this.setComponent = function(val) {
component = val;
for (var key in val) {
if (typeof(val[key])==«function») {
addMethod(key, val[key]);
}
}
};
>расширив «интересные» методы и оставив ностальные в покое?
>или это будет уже другой паттерн?
Это будет слишком просто — пройти по списку функций и сделать такие же. Но у автора есть это в комментарии — только я не понял, почему это плохо.
this.setComponent = function(val) {
component = val;
for (var key in val) {
if (typeof(val[key])==«function») {
addMethod(key, val[key]);
}
}
};
У меня есть большущий вопрос: какой паттерн нужен для эмуляции паттернов, требующих callback сервера? С использованием современных браузеров, желательно кроссбраузерный.
Например, я хочу чтобы раз в полчаса сервер мог обртиться к загруженной у клиента страничке (eg, 1 секунда), посмотреть сделала ли она нужное дело (eg, отрисовала гуй). И скажем, RPC'шнуть какой-нибудь JS-метод из клиента, например попросить перерисовать что-нибудь еще.
Как сделать это когда есть _нормальный_ клиент и _нормальный_ сервер — понятно. Как сделать это с помощью современного браузера и стандартного Apache? Ладно, а _нестандартного_ Апача, какой модуль нужно написать? Реализовал ли его уже кто-то?
Например, я хочу чтобы раз в полчаса сервер мог обртиться к загруженной у клиента страничке (eg, 1 секунда), посмотреть сделала ли она нужное дело (eg, отрисовала гуй). И скажем, RPC'шнуть какой-нибудь JS-метод из клиента, например попросить перерисовать что-нибудь еще.
Как сделать это когда есть _нормальный_ клиент и _нормальный_ сервер — понятно. Как сделать это с помощью современного браузера и стандартного Apache? Ладно, а _нестандартного_ Апача, какой модуль нужно написать? Реализовал ли его уже кто-то?
По моему надо смотреть в сторону Comet
Гугль пробегал и оставил это здесь: en.wikipedia.org/wiki/Comet_(programming)
Про паттерны в JS очень (очень!, очень! :)) рекомендую «Pro Javascript design patterns» (не уверен, но на русский ее кажется не переводили, хотя я особо и не искал).
IMHO, книга из серии musthave для JS-разработчика.
IMHO, книга из серии musthave для JS-разработчика.
А скачать ее можно здесь: book.pdfchm.net/Pro-Javascript-Design-Patterns/9781590599082/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация паттерна декоратор на JS