Comments 97
UFO just landed and posted this here
Автор в эпоху джекверей создал деревянный велосипед и описал его как ядерный реактор.
да-да, я че то видел в статье по поводу джекверей, но мой маленький мозг не может понять почему это нереализуемо на них.
да-да, я че то видел в статье по поводу джекверей, но мой маленький мозг не может понять почему это нереализуемо на них.
-14
не реализуемо что?
0
«деревянный велосипед» изобрели светила современного программирования, те самые GoF, вы можете погуглить что такое «шаблоны проектирования» (да ту же вики почитать).
вы не дочитали всего-навсего реализацию на JS с очень незначительными вариациями от классики, в отличие от множества других примеров декоратора когда «работоспособность остается», а профит от подхода много меньше.
вы не дочитали всего-навсего реализацию на JS с очень незначительными вариациями от классики, в отличие от множества других примеров декоратора когда «работоспособность остается», а профит от подхода много меньше.
0
UFO just landed and posted this here
Если пользоваться одними JQuery, мозг не только станет маленьким, но еще и полностью гладким
+9
Если пользоваться одними шаблонами, мозг не только станет маленьким, но еще и полностью гладким.
-8
Ну и за что минусим?
Я тут, если что, истину пытаюсь донести. Шаблоны ни разу не панацея, от некоторых вообще стоит держаться подальше.
Ну и еще один гвоздь: решая задачу, отталкиваться надо именно от нее, а не от манящего решения в виде шаблона. Часто бывает, что шаблоны применяют без повода (как и ООП), а потом в коде черт ногу сломит.
Это как не видеть лес за деревьями, то бишь, конечно, настоящее решение за шаблонами.
Я тут, если что, истину пытаюсь донести. Шаблоны ни разу не панацея, от некоторых вообще стоит держаться подальше.
Ну и еще один гвоздь: решая задачу, отталкиваться надо именно от нее, а не от манящего решения в виде шаблона. Часто бывает, что шаблоны применяют без повода (как и ООП), а потом в коде черт ногу сломит.
Это как не видеть лес за деревьями, то бишь, конечно, настоящее решение за шаблонами.
-7
Шаблоны это лишь способ организации архитектуры, никто не мешает тебе реализовывать идею именно так, как ее нужно реализовать наилучшим образом; что шаблоны и ООП отлично структурируют код и упрощают его повторное использование (если конечно уметь правильно реализовывать и ООП, и шаблоны).
+4
слово «что» было лишним :)
0
>если конечно уметь правильно реализовывать и ООП, и шаблоны
О. А что есть «правильно»? И как реализовывать ООП?
О. А что есть «правильно»? И как реализовывать ООП?
0
Правильно реализовывать шаблоны — значит реализовывать их именно так, как говорится в спецификации к шаблону, это же очевидно)
На тему ООП в javascript существует куча статей, в частности msdn.microsoft.com/ru-ru/magazine/cc163419.aspx
На тему ООП в javascript существует куча статей, в частности msdn.microsoft.com/ru-ru/magazine/cc163419.aspx
+1
>Правильно реализовывать шаблоны — значит реализовывать их именно так, как говорится в спецификации к шаблону, это же очевидно)
Я не спрашивал про шаблоны. Я спрашивал про «правильность» и «реализацию ООП» (очевидно «правильную»).
Я не спрашивал про шаблоны. Я спрашивал про «правильность» и «реализацию ООП» (очевидно «правильную»).
0
Вы в чем-то нашли не«правильность»?
0
Я ответил и про шаблоны, и про ООП. Зачем холиварить? :)
0
я подумал, что я что-то пропустил
0
Вы не ответили про «правильность». Либо дайте мне его определение, либо не применяйте его в споре.
0
Не вижу смысла в очевидных вещах, ну да ладно. Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
0
>Не вижу смысла в очевидных вещах, ну да ладно.
Отличный демагогический прием.
>Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
Что такое «архитектура ООП»? Как ее применить к алгоритму? Причем тут синтаксис?
Отличный демагогический прием.
>Под правильностью реализации ООП я понимаю применение архитектуры ООП к некоему алгоритму в рамках синтаксиса, который поддерживается тем или иным языком программирования.
Что такое «архитектура ООП»? Как ее применить к алгоритму? Причем тут синтаксис?
0
> Что такое «архитектура ООП»
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++ — довольно разные вещи
+2
>> Что такое «архитектура ООП»
>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
Расскажите своими словами про «архтитектуру ООП». У вас это хорошо получается. Узнаю много нового.
>> Как ее применить к алгоритму
>С помощью мозга, видимо
А конструктивно можете объяснить?
>Синтаксис при среде реализации алгоритма.
ЛОЛШТО?
-2
Выучи сначала, что такое «архитектура» и какое отношение это слово имеет к программированию.
> С помощью мозга, видимо
У тебя он гладкий, что и требовалось показать.
> Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
Синтаксис в JS и C++ довольно похожий (Си-подобный же), зато разная модель памяти (в JS с выделением машинной памяти вообще не сталкиваешься), хотя модель вычислений примерно одна и та же (вычисление в окружении, но оно тоже по-разному выглядит, ибо в JS есть функции первого класса и замыкания).
Короче, учи матчасть, а то я тут уже несколько раз под стол падал от твоих сентенций.
> С помощью мозга, видимо
У тебя он гладкий, что и требовалось показать.
> Синтаксис при среде реализации алгоритма. ООП в javascript и в C++ — довольно разные вещи
Синтаксис в JS и C++ довольно похожий (Си-подобный же), зато разная модель памяти (в JS с выделением машинной памяти вообще не сталкиваешься), хотя модель вычислений примерно одна и та же (вычисление в окружении, но оно тоже по-разному выглядит, ибо в JS есть функции первого класса и замыкания).
Короче, учи матчасть, а то я тут уже несколько раз под стол падал от твоих сентенций.
0
синтаксис, я так понимаю, применялся в значении «реализация на конкретном языке». сходства у любых языков имеются.
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете
+1
> синтаксис, я так понимаю, применялся в значении «реализация на конкретном языке».
Интересное значение, раньше не встречал. Я пользуюсь другим, и всем рекомендую: синтаксис это набор правил, определяющих множество комбинаций символов, которые считаются синтаксически корректными программами какого-то языка.
> сходства у любых языков имеются.
Это только в теории. На практике же, дай вам программку на Haskell, вы ее не осилите без должной подготовки — слишком мало общего с JS на первый, второй и n-ый взгляд. :) (на Haskell пишут совсем не так, как на JS — «культура» сказывается)
> я так и не понял, почему у ap3rus'а мозг гладкий?
Потому что он, как попугай, повторяет чьи-то истины, о которых не знает сам.
> Вы доступно, с толком, с расстановкой это аргументируете
Я уже аргументировал, толку ноль, зато минусов нахватался. :) За что? За то, что тут кучка идиотов возводит шоблончеги в божество какое-то, а я посмел его осквернить.
А вообще-то не надо признавать, чей мозг мелкий и гладкий, читайте книжки просто. ;-)
Интересное значение, раньше не встречал. Я пользуюсь другим, и всем рекомендую: синтаксис это набор правил, определяющих множество комбинаций символов, которые считаются синтаксически корректными программами какого-то языка.
> сходства у любых языков имеются.
Это только в теории. На практике же, дай вам программку на Haskell, вы ее не осилите без должной подготовки — слишком мало общего с JS на первый, второй и n-ый взгляд. :) (на Haskell пишут совсем не так, как на JS — «культура» сказывается)
> я так и не понял, почему у ap3rus'а мозг гладкий?
Потому что он, как попугай, повторяет чьи-то истины, о которых не знает сам.
> Вы доступно, с толком, с расстановкой это аргументируете
Я уже аргументировал, толку ноль, зато минусов нахватался. :) За что? За то, что тут кучка идиотов возводит шоблончеги в божество какое-то, а я посмел его осквернить.
А вообще-то не надо признавать, чей мозг мелкий и гладкий, читайте книжки просто. ;-)
0
> Интересное значение, раньше не встречал.
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
+1
> «Синтаксис в JS и C++ довольно похожий»
Я не говорил, что он разный, я сказал что реализация ООП в javascript и в C++ довольно отличается, в Javascript нет наследования, но есть прототипирование, в javascript любой объект или функция является одновременно и объектом, проектирование ООП модели следует делать полагаясь на эти различия.
Я не говорил, что он разный, я сказал что реализация ООП в javascript и в C++ довольно отличается, в Javascript нет наследования, но есть прототипирование, в javascript любой объект или функция является одновременно и объектом, проектирование ООП модели следует делать полагаясь на эти различия.
+1
> проектирование ООП модели следует делать полагаясь на эти различия
Модели чего? Реального мира, наверное. А где вы в реальном мире видели «декораторов»? :) (нет, ну конечно же, можно придумать физическую аналогию; я тут придираюсь к слову «модель» просто)
Но вы съехали куда-то не туда. ООП (абстракция данных, если хотите) с шаблонами (костылями, если угодно) не являются ответом на все вопросы! Надо знать, когда ООП применимо, а когда нет, а в распеаренных книжках Буча и прочих «светил» об этом ни слова.
Модели чего? Реального мира, наверное. А где вы в реальном мире видели «декораторов»? :) (нет, ну конечно же, можно придумать физическую аналогию; я тут придираюсь к слову «модель» просто)
Но вы съехали куда-то не туда. ООП (абстракция данных, если хотите) с шаблонами (костылями, если угодно) не являются ответом на все вопросы! Надо знать, когда ООП применимо, а когда нет, а в распеаренных книжках Буча и прочих «светил» об этом ни слова.
0
> Модели чего? Реального мира, наверное.
Такое чувство, будто я разговариваю с учителем литературы)
> Надо знать, когда ООП применимо, а когда нет… а в распеаренных книжках Буча
С учителем я погорячился ;)
Я как раз об этом и говорю, нужно использовать свой мозг, перед тем, как пытаться что-либо применить. А читать книжки нужно, хотя бы для того, чтобы знать что такое ООП.
Такое чувство, будто я разговариваю с учителем литературы)
> Надо знать, когда ООП применимо, а когда нет… а в распеаренных книжках Буча
С учителем я погорячился ;)
Я как раз об этом и говорю, нужно использовать свой мозг, перед тем, как пытаться что-либо применить. А читать книжки нужно, хотя бы для того, чтобы знать что такое ООП.
+1
а кто говорил, что это панацея?
0
Ну а кто применяет шаблоны там, где не надо?
PS я определяю рамки применимости шаблонов как очень скромные: там, где язык не позволяет выразить какую-то мысль явно, приходится использовать шаблоны, дабы обойти ограничения. Примеры: функции первого класса и замыкания.
PS я определяю рамки применимости шаблонов как очень скромные: там, где язык не позволяет выразить какую-то мысль явно, приходится использовать шаблоны, дабы обойти ограничения. Примеры: функции первого класса и замыкания.
0
В вашем же случае: отсутствие первоклассных сообщений (и следовательно, возможности делегировать сообщение другому объекту) заставляет юзать какой-то там «декоратор» (название-то какое!).
Вообще-то делегировать в JS можно посредством прототипов, надо подумать.
Но вы же не в ту степь ломанулись сразу же: абстрагировать данные там, где нужно абстрагировать алгоритм!
А все отчего? От того, что я писал выше: отталкиваться надо от проблемы, а не от шаблона.
Вообще-то делегировать в JS можно посредством прототипов, надо подумать.
Но вы же не в ту степь ломанулись сразу же: абстрагировать данные там, где нужно абстрагировать алгоритм!
А все отчего? От того, что я писал выше: отталкиваться надо от проблемы, а не от шаблона.
0
не буду утверждать, что данный пример — эталон js+декоратор, но вполне себе хороший пример. сможете привести получше — скажу спасибо
0
Дык я ж не о том совсем! Я исключительно о применении шаблона не по назначению.
Что же касается примеров шаблона — зачем они? Мне кажется, если у человека возникает необходимость в делегировании в JS — то он берет и использует прототипы.
Что же касается примеров шаблона — зачем они? Мне кажется, если у человека возникает необходимость в делегировании в JS — то он берет и использует прототипы.
0
видимо, я чего-то не понимаю.
делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект. при этом, сам он не расширяет функциональность «вложенного» метода. если он что-то делает, а потом вызывает — это декоратор.
можно этот же пример сделать с помощью «не особо делегирования», нам понадобятся следующие классы: BaseScroll_plus_Buttons, BaseScroll_plus_PageNum, BaseScroll_plus_Buttons_plus_PageNum — и еще столько же для AnimScroll.
А если мы не хотим иметь шесть классов, то можно сделать метод компоненты и декораторы :)
делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект. при этом, сам он не расширяет функциональность «вложенного» метода. если он что-то делает, а потом вызывает — это декоратор.
можно этот же пример сделать с помощью «не особо делегирования», нам понадобятся следующие классы: BaseScroll_plus_Buttons, BaseScroll_plus_PageNum, BaseScroll_plus_Buttons_plus_PageNum — и еще столько же для AnimScroll.
А если мы не хотим иметь шесть классов, то можно сделать метод компоненты и декораторы :)
+1
> делегирование это когда есть объект, который перенаправляет методы в другой инкапсулированный объект.
Да, но по ходу действия он может все что хочет делать с сообщением. ;) Делегирование и наследование — это две стороны одной монеты.
Кстати, объект-получатель может быть неинкапсулированным, а каким-нибудь глобальным. Достаточно, чтобы он был замкнут относительно объекта-прокси.
Да, но по ходу действия он может все что хочет делать с сообщением. ;) Делегирование и наследование — это две стороны одной монеты.
Кстати, объект-получатель может быть неинкапсулированным, а каким-нибудь глобальным. Достаточно, чтобы он был замкнут относительно объекта-прокси.
0
есть несколько, уже упомянутых, понятий: делегирование, декорирование, наследование. они, правда, в разных весовых категориях, но можно взять абсолютно любой код, выдрать из него ± любой кусок и сказать: «здесь употребляется (делегирование|декорирование|наследование)».
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
0
Это не понятия, это каша.
Понятия — это сообщение, и передача сообщения которое тоже есть сообщение. :)
> передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
Нет. Допустим, что «Класс» это глобальный объект, которому мы можем отправить сообщение, чтобы определить новый класс. Смотрим Smalltalk и удивляемся.
Понятия — это сообщение, и передача сообщения которое тоже есть сообщение. :)
> передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
Нет. Допустим, что «Класс» это глобальный объект, которому мы можем отправить сообщение, чтобы определить новый класс. Смотрим Smalltalk и удивляемся.
0
да, единственный способ заставить объект работать — вызвать его метод (сообщение передать). когда мы говорим классу: «new» — нам возвращается новый объект. чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
0
> да, единственный способ заставить объект работать — вызвать его метод (сообщение передать)
Передача сообщений — более общее понятие. Бывают синхронные, асинхронные, бывают с продолжением, бывают с замыканием и тп. Передача сообщений это модель вычисления, по мощности эквивалентная машине Тьюринга и лямбда-исчислению.
> чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
Понятия «наследование», «полиморфизм», «делегирование» и пр. в мейнстримовых языках являются кашей из-за отсутствия их четкого формального определения. Это самое определение должно схватить самую *суть*, а не сиюминутные прихоти «орхетекторов» языка.
И напоследок, пару пойнтов.
В настоящем ООП всякие костыли вроде таких любимых народом шаблончегов просто не нужны (в них не возникает необходимости, так то!).
Шаблоны проектирования являются неудачными абстракциями из-за того, что не уменьшают количество писанины, не позволяют строить на их основе другие абстракции, и только худо-бедно позволяют программисту размышлять над кодом.
Dixi.
Передача сообщений — более общее понятие. Бывают синхронные, асинхронные, бывают с продолжением, бывают с замыканием и тп. Передача сообщений это модель вычисления, по мощности эквивалентная машине Тьюринга и лямбда-исчислению.
> чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
Понятия «наследование», «полиморфизм», «делегирование» и пр. в мейнстримовых языках являются кашей из-за отсутствия их четкого формального определения. Это самое определение должно схватить самую *суть*, а не сиюминутные прихоти «орхетекторов» языка.
И напоследок, пару пойнтов.
В настоящем ООП всякие костыли вроде таких любимых народом шаблончегов просто не нужны (в них не возникает необходимости, так то!).
Шаблоны проектирования являются неудачными абстракциями из-за того, что не уменьшают количество писанины, не позволяют строить на их основе другие абстракции, и только худо-бедно позволяют программисту размышлять над кодом.
Dixi.
0
/me как бы вторит К.О.: работа выполнена, конечно же, из академического интереса?
+1
изначально, да, был чисто академический интерес. сначала посмотрел примеры, книгу почитал, написал на js абстрактное решение. потом начал думать о хоть каком-нибудь примере из реальной жизни, и додумался до вот такой штучки.
и вот когда я до неё додумался :) понял профитность реализации «как написано», а не как умею.
и вот когда я до неё додумался :) понял профитность реализации «как написано», а не как умею.
0
Статья, что называется в руку. Третий день думаю как реализовать взаимодействие между «классами». Спасибо и низкий поклон! :)
0
Вы уж меня простите, я не стал полнсотью читать статью (потому что я не люблю кодить на жс без фремйворка).
Я не знаком с паттернами, но не так давно я делал один сайт, и у меня в голове зародилось кое-что похожее.
Но комментарий не об этом. Хочу написать, где вообще в JS может пригодится подобное.
Дано: сайт, на нём дизайнер родил аж три галереи. Функционал похожий: область где показывается текущая картинка и область filmstripa. Но дизайн везде разный, филмстрип где вертикальный, где горизонтальный, анимации разные, где-то нужно оверлеить дополнительную информацию.
Тогда я написал базовый класс (используя мутулсы), управляющий всем этим безобразием, а для каждой конкретной галереи он доопределялся своими классами: добавлялись какие-то действия на события, уточнялись настройки. Вышло чертовски прикольно и кратко (сильно короче листинга в посте).
Я не знаком с паттернами, но не так давно я делал один сайт, и у меня в голове зародилось кое-что похожее.
Но комментарий не об этом. Хочу написать, где вообще в JS может пригодится подобное.
Дано: сайт, на нём дизайнер родил аж три галереи. Функционал похожий: область где показывается текущая картинка и область filmstripa. Но дизайн везде разный, филмстрип где вертикальный, где горизонтальный, анимации разные, где-то нужно оверлеить дополнительную информацию.
Тогда я написал базовый класс (используя мутулсы), управляющий всем этим безобразием, а для каждой конкретной галереи он доопределялся своими классами: добавлялись какие-то действия на события, уточнялись настройки. Вышло чертовски прикольно и кратко (сильно короче листинга в посте).
+1
Хорошо, интересно.
Вот только как это можно применить, зачем это?
Вот только как это можно применить, зачем это?
0
Прямо над вашим комментарием я написал хороший пример того, как можно применить что-то подобное.
И думаю это не единственная ситуация.
И думаю это не единственная ситуация.
+3
не хотелось бы отвечать «где угодно» или копипастить, попробую «от души» ответить, голосом сердца :)
обычно, приступая к написанию чего-либо, мы изучаем что нам надо сделать и берем в рассчет только то, что от нас хотят. мы готовы к переделкам очень относительно, но пока наше творение находится «внутри функции», или там в объекте, то чтобы что-то переделать, нам надо или положиться на удачу, или изучить функционал целиком. надо переделать второй раз — снова или положиться на удачу, или изучить функционал целиком.
что бы то ни было: калькуляторы, фотогалереи, система сообщений между пользователями на сайте — корзина отдельно, яйца отдельно :)
только я не призываю юзать это везде. абсолютно не призываю. каждую задачу можно решить бесконечным числом способов и нету какого-то универсального.
калькулятор считает размер скидки. есть 5 критериев. их можно взять и написать один за другим. надо выкинуть 3й и добавить новый — изучаем всю логику и режем кусочки, или не лезем в логику рассчетов, а удаляем в конструкторе подключение 3-го и пишем еще один. конечно, не всегда можно найти 5 обособленных критериев.
фотогалерея уже нашлась в комментах, см. выше.
система сообщений между пользователями на сайте может отображать кол-во новых сообщений в статус баре, и когда понадобится добавить алерт о новом сообщении, мы сможем сделать это быстро, а когда понадобится его удалить, не будет никаких сомнений в работоспособности системы. хотя, имхо, тут лучше наблюдатель задействовать :)
повторюсь, я не призываю юзать декоратор везде, а только там, где это действительно профитно.
обычно, приступая к написанию чего-либо, мы изучаем что нам надо сделать и берем в рассчет только то, что от нас хотят. мы готовы к переделкам очень относительно, но пока наше творение находится «внутри функции», или там в объекте, то чтобы что-то переделать, нам надо или положиться на удачу, или изучить функционал целиком. надо переделать второй раз — снова или положиться на удачу, или изучить функционал целиком.
что бы то ни было: калькуляторы, фотогалереи, система сообщений между пользователями на сайте — корзина отдельно, яйца отдельно :)
только я не призываю юзать это везде. абсолютно не призываю. каждую задачу можно решить бесконечным числом способов и нету какого-то универсального.
калькулятор считает размер скидки. есть 5 критериев. их можно взять и написать один за другим. надо выкинуть 3й и добавить новый — изучаем всю логику и режем кусочки, или не лезем в логику рассчетов, а удаляем в конструкторе подключение 3-го и пишем еще один. конечно, не всегда можно найти 5 обособленных критериев.
фотогалерея уже нашлась в комментах, см. выше.
система сообщений между пользователями на сайте может отображать кол-во новых сообщений в статус баре, и когда понадобится добавить алерт о новом сообщении, мы сможем сделать это быстро, а когда понадобится его удалить, не будет никаких сомнений в работоспособности системы. хотя, имхо, тут лучше наблюдатель задействовать :)
повторюсь, я не призываю юзать декоратор везде, а только там, где это действительно профитно.
+3
К сожалению я не знаю js достаточно хорошо, поэтому хочу спросить — если в нем какой-нибудь аналог системы перехвата несуществующих функций объекта, как например метод __call() в пхп или класс Proxy в ас3?
Если есть то по идее можно было бы с помощью него улучшить абстрактный декоратор, реализовав в нем такую систему вместо перечисления функций декорируемого объекта
Если есть то по идее можно было бы с помощью него улучшить абстрактный декоратор, реализовав в нем такую систему вместо перечисления функций декорируемого объекта
0
на сколько я знаю, нету.
можно конечно exception-ы хватать и как-то обрабатывать, но это тот еще изврат :)
можно конечно exception-ы хватать и как-то обрабатывать, но это тот еще изврат :)
0
именно перехватывать несуществующие методы нельзя, только если с помощью 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" и не думаю, что это хорошо
… но я бы лучше перечислял методы, ничего зазорного я в этом не вижу
0
я кое-чего у тебя не понял, ты написал метод
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? Нравится хранить мусор? =)
0
а, если их не копировать, то как потом в декораторе вызывать?
т.е. у компонента есть fn2, а у декоратора его нет — как вызвать fn2, обращаясь к декоратору и не проверяя каждый раз наличие fn2?
т.е. у компонента есть fn2, а у декоратора его нет — как вызвать fn2, обращаясь к декоратору и не проверяя каждый раз наличие fn2?
0
А действительно, с утра мозг сбуксовал)
Я хотел сказать другое, у IDecorator есть метод setComponent(val), который задает методы из объекта val, но если этот метод вызвать два раза для разных объектов, мусор скопится, можно было бы вставить проверку на то, что у IDecorator уже задан component, удалить все его методы, и только потом добавить новые методы. Либо же просто задание компонента перенести в конструктор IDecorator
Я хотел сказать другое, у IDecorator есть метод setComponent(val), который задает методы из объекта val, но если этот метод вызвать два раза для разных объектов, мусор скопится, можно было бы вставить проверку на то, что у IDecorator уже задан component, удалить все его методы, и только потом добавить новые методы. Либо же просто задание компонента перенести в конструктор IDecorator
0
d.fn2(2); // «Component > fn2 2» и не думаю, что это хорошо
ой, извиняюсь, поведение правильное
ой, извиняюсь, поведение правильное
0
упс, «есть ли» вместо «если» в первой строке.
0
Не уловил кошерности в примере.
На сколько я знаю этот шаблон нам нужен, когда у нас есть GOD-объект, а от него нам надо только А, Б и В.
Или, когда мы религиозные экстремисты и не приемлем иного фреймворка, нежели %framework_name%, и внешний компонент для скорости, оборачиваем в декоратор, который кошерен.
На сколько я знаю этот шаблон нам нужен, когда у нас есть GOD-объект, а от него нам надо только А, Б и В.
Или, когда мы религиозные экстремисты и не приемлем иного фреймворка, нежели %framework_name%, и внешний компонент для скорости, оборачиваем в декоратор, который кошерен.
0
GOD-объект? кошерность в использовании: нужны кнопки — добавляем кнопки, нужен индикатор страницы — добалвяем индикатор страницы.
0
[зануда]Подсветите плиз код, а то не очень удобно его читать[/зануда]
0
Плоховастенько (то бишь есть куда стремиться), ибо много кода.
Недавно (пару месяцев назад) писал анимацию на 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');
-2
Хех, и тут минусы. Вы бы разобрались, в чем дело-то сперва.
ОП просто-напросто нафигачил целое полотно из-за своего незнания, что есть такая штука, как абстракция алгоритма.
Зато шаблоны же, еба.
ОП просто-напросто нафигачил целое полотно из-за своего незнания, что есть такая штука, как абстракция алгоритма.
Зато шаблоны же, еба.
0
статья о шаблоне, а не о анимации.
+1
Статья приведена как пример использования алгоритмической абстракции, о которой любители шоблончегов и слыхом не слыхивали.
0
Вам шашечки или ехать?
-1
аллоу, какие «шашечки или ехать»? статья называется «Реализация паттерна декоратор на JS», неужто она должна быть про анимацию, или абстракцию алгоритма?
+1
Вы знаете, мое мнение — данный пример не пригоден за рамками академического интереса. Паттерны GOF довольно универсальны, но зацикливаться на них не стоит. В книге они реализованы для C++ и Smaltalk, но не стоит забывать об уникальной специфике каждого языка. Так например родились на свет паттерны J2EE. JS — клиентский язык, и в наших интересах писать крайне сжатый и быстрый код. Паттерны же в свою очередь смотрят в сторону повторного использования и простоты расширения, забывая об объеме кода — для серверных приложений это не столь принципиально. В этой книге имеется описание паттерна декоратор, но контекст применения совершенно иной, не dom-виджеты. Если честно — еще не читал, в ближайшее время прочитаю и вам советую: )
+1
JS — клиентский язык
Не согласен. Реализация VM этого языка обычно встаивается в браузеры или Qt-программы, но называть целый язык клиенским — не надо. Язык вообще не может быть серверным/клиентским, только VM.
Вот вам пример серверной VM языка Javascript code.google.com/p/v8cgi/
А вот даже фреймворк, на основе небезызвестного MooTools для серверного Javascript raccoon.keetology.com/
+1
Так что, по моему мнению, если не сейчас, то в скором будущем, реализации паттернов на Javascript станут нужными и будут использоватся на практике
+1
Мы говорим о чем? О том коде, который клиент загружает себе каждый раз? (не думаем сейчас о кеше). Лично для меня JS прежде всего это клиентский язык. В данном топике речь идет о джаваскриптовом dom-скриптинге — не клиентские скрипты по вашему мнению??
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Вы не считайте, что до паттернов в JS никто еще не додумался, почитайте блог Дена Эдвардса например, все на свои места встанет.
Дело в том, что я сам когда стал въезжать в паттерны, стал их тутже реализовывать в JS, потом пришло чувство осознания, что я не самый хитрый.
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Вы не считайте, что до паттернов в JS никто еще не додумался, почитайте блог Дена Эдвардса например, все на свои места встанет.
Дело в том, что я сам когда стал въезжать в паттерны, стал их тутже реализовывать в JS, потом пришло чувство осознания, что я не самый хитрый.
0
Если говорить о серверном применении, естественно нам безразличен размер скриптов и интересует возможность расширения.
Именно об этом я и говорю. Вы сказали что
данный пример не пригоден за рамками академического интереса.
так как
JS — клиентский язык
Я дал вам пример того где данный пример пригоден к использованию. Автор сделал рабочий пример в среде браузера, но никто не мешает пользоватся этим кодом на стороне сервера.
0
Ерунда. Для js объём кода тоже давно не главное, всегда можно обфусцировать/запаковать, да и не бывает его слишком много в подавляющем большинстве случаев. Так что то что паттерны так увеличить код что даже обфусцированный он будет долго загружаться клиентом — полнейшая чушь. Хотя и область применения паттернов в JS мала, реально они требуются если пишете большой проект типа FCK Editor, в остальном только запутают код.
+1
dom-виджет я выбрал, потому что визуальный пример с формочкой всегда понятнее, чем код, или описание кода.
книгу надо бы почитать, спасибо за ссылку, но зацикливаться на ней я тоже буду :)
краткость кода это хорошо, но его модифицируемость — гораздо лучше. быстрый код? не думаю, что эта штука будет тормозить. а реализовывать функционал, требующий максимальной скорости нужно, как бы это, «на языке», без архитектуры вообще… не знаю, как это по-человечески сказать :)
у меня тоже есть отступления от темы. Scroll, и Decorator — базовые классы, а не интерфейсы, из-за локальных переменных.
я не зацикливаюсь, просто под декоратором люди понимают все, что угодно: AOP, колбэки, перекидывание функции (именно функции, у которой return число возвращает) аргументом при инстанцировании декоратора. «но мне бы хотелось поделиться реализацией весьма близкой к GoF'у».
пример имеет, по сути, один JS-недостаток — объем кода. это плохо, но, имхо, еще не причина оставлять его в рамках академического интереса.
книгу надо бы почитать, спасибо за ссылку, но зацикливаться на ней я тоже буду :)
краткость кода это хорошо, но его модифицируемость — гораздо лучше. быстрый код? не думаю, что эта штука будет тормозить. а реализовывать функционал, требующий максимальной скорости нужно, как бы это, «на языке», без архитектуры вообще… не знаю, как это по-человечески сказать :)
у меня тоже есть отступления от темы. Scroll, и Decorator — базовые классы, а не интерфейсы, из-за локальных переменных.
я не зацикливаюсь, просто под декоратором люди понимают все, что угодно: AOP, колбэки, перекидывание функции (именно функции, у которой return число возвращает) аргументом при инстанцировании декоратора. «но мне бы хотелось поделиться реализацией весьма близкой к GoF'у».
пример имеет, по сути, один JS-недостаток — объем кода. это плохо, но, имхо, еще не причина оставлять его в рамках академического интереса.
0
после такого дисклэймера, напрашивается постскриптум:
за время реализации не пострадало ни одной функции :)
по оформлению:
я бы заподозрил очень малое количество читателей этого блога со встроенным в мозгу движком JS.
хотябы раскрашенный код был бы гораздо читабельнее.
а ещё лучше — сделать в духе документации по jquery:
код + рабочий пример
по теме:
а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс, расширив «интересные» методы и оставив ностальные в покое?
или это будет уже другой паттерн?
за время реализации не пострадало ни одной функции :)
по оформлению:
я бы заподозрил очень малое количество читателей этого блога со встроенным в мозгу движком JS.
хотябы раскрашенный код был бы гораздо читабельнее.
а ещё лучше — сделать в духе документации по jquery:
код + рабочий пример
по теме:
Все компоненты должны иметь одинаковый интерфейс,
а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс, расширив «интересные» методы и оставив ностальные в покое?
или это будет уже другой паттерн?
+1
>а что мешает использовать интроспекцию кмпонента и _породить_ такойже интерфейс,
>расширив «интересные» методы и оставив ностальные в покое?
>или это будет уже другой паттерн?
Это будет слишком просто — пройти по списку функций и сделать такие же. Но у автора есть это в комментарии — только я не понял, почему это плохо.
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]);
}
}
};
0
У меня есть большущий вопрос: какой паттерн нужен для эмуляции паттернов, требующих callback сервера? С использованием современных браузеров, желательно кроссбраузерный.
Например, я хочу чтобы раз в полчаса сервер мог обртиться к загруженной у клиента страничке (eg, 1 секунда), посмотреть сделала ли она нужное дело (eg, отрисовала гуй). И скажем, RPC'шнуть какой-нибудь JS-метод из клиента, например попросить перерисовать что-нибудь еще.
Как сделать это когда есть _нормальный_ клиент и _нормальный_ сервер — понятно. Как сделать это с помощью современного браузера и стандартного Apache? Ладно, а _нестандартного_ Апача, какой модуль нужно написать? Реализовал ли его уже кто-то?
Например, я хочу чтобы раз в полчаса сервер мог обртиться к загруженной у клиента страничке (eg, 1 секунда), посмотреть сделала ли она нужное дело (eg, отрисовала гуй). И скажем, RPC'шнуть какой-нибудь JS-метод из клиента, например попросить перерисовать что-нибудь еще.
Как сделать это когда есть _нормальный_ клиент и _нормальный_ сервер — понятно. Как сделать это с помощью современного браузера и стандартного Apache? Ладно, а _нестандартного_ Апача, какой модуль нужно написать? Реализовал ли его уже кто-то?
0
По моему надо смотреть в сторону Comet
+1
Гугль пробегал и оставил это здесь: en.wikipedia.org/wiki/Comet_(programming)
+1
Про паттерны в JS очень (очень!, очень! :)) рекомендую «Pro Javascript design patterns» (не уверен, но на русский ее кажется не переводили, хотя я особо и не искал).
IMHO, книга из серии musthave для JS-разработчика.
IMHO, книга из серии musthave для JS-разработчика.
+1
А скачать ее можно здесь: book.pdfchm.net/Pro-Javascript-Design-Patterns/9781590599082/
+1
Sign up to leave a comment.
Реализация паттерна декоратор на JS