1 Востаннє редагувалося mrChex (04.08.2012 11:20:33)

Тема: Prototype VS Classic OOP (JavaScript)

Тема на яку немає відповіді. Всі знають що в JavaScript прототипна модель, що ускладнює фундаментальне розуміння мови. Кожен, хто почав розробку на js після якоїсь об’єктної мови бажає бачити перед собою звичну структуру із классів та методів. Тому і створюються фреймворки які допоможуть зробити з незрозумілого javascript щось звичне.

На цьому місці я почав шукати на хабрі статтю де людина розповідала про свою розробку ООП в js, перший коментар до якої: "Поздравляю, Вы изобрели MooTools", а другий містив в собі що найменше 20 посиланнь на аналогічні проекти. Натомість знайшов пост, з яким я згоден http://habrahabr.ru/post/111393/ , а в коментарях, звичайно, пекельна дискусія.

По цьому питання: як Ви пишете javascript код і чому? Прості функції, прототипи або класи, такі як в MooTools?

Люблю Python, Django, Android, html5. Занимаюсь платежными инструментами в онлайне и оффлайне.
Подякували: Replace, bunyk, leofun013

2

Re: Prototype VS Classic OOP (JavaScript)

Насправді в основному нічого складного програмувати для сайтів не доводиться, тому використовую звичайні функції. Останнім часом почав використовувати стиль описання парамерів та функції як в JQuery, інколи прототипи, але здається що це сильно ускладнює розуміння того що написано. Можливо все залежить від проекту.

3

Re: Prototype VS Classic OOP (JavaScript)

Ок, раз мнений пока нет напишу о своем личном, конкретном опыте. На русском, т.к. удобней излагать объемные мысли именно так.

Оговорюсь сразу, я поклонник MooTools еще с тех времен когда на mootools.org были примеры реализации всяких там аккордионов и других эффектиков. Позже все разнесли по Code и More, подняли порог вхождения в фреймворк, стали взрослей. С jQuery знаком посредственно, но это, на сколько мне известно, более библиотека для эффектов (кидайте уже камни), с очень низким порогом вхождения. Там очень удобные селекторы, повторяющие CSS и вообще все очень мило, куча плагинов и все такое.

Опыт:
Представьте себе большое html5 приложение под WebKit с десятками различных зависимых и не зависимых друг от друга страниц, настройки которых хранятся в сотнях json файлов.

Речь о интерфейсе платежного терминала. Приблезительно понять о чем можно из моего видео-демонстрации: http://www.youtube.com/watch?v=wiXzU6R6NRw

Все этапы работы, прорисовки интерфейсов и эффекты -- javascript. Задача сделать плавный, быстрый интерфейс, который бы работал на старом оборудовании, при этом перезагрузка страницы нежелательна и от этого нужно уйти. Реакция на нажатие должна быть мгновенна и очевидна, срок разработки -- "ВНЕЗАПНО".

Подход:
Как бы вы подошли к реализации подобного? Уточню, в основе всего лежит масштабируемость, в какой-то момент может быть сломана концепция, из-за чего нужно уменьшить количество неизбежных переделок.

Первое что отпадает само собой -- функции с названиями типа mainPage_show(), mainPage_changeCat(), mainPage_selectProvider(). Сейчас реального js кода - 186кб в 23х файлах не учитывая mootools и вся эта логика должна оставаться читаемой при любых объемах.

Прототипы отпадают из-за того что я их не понимаю. Однако, есть код который реализует инпуты, в нем как раз используются прототипы. Состоит из 300 строк и является нечитаемым практически полностью, так что в эту сторону даже не хочется смотреть в таком проекте.

ООП которое предоставляет мутулз или простое представление объектов в виде:

var MyClass = {
  "foo": function(args){
    return "bar"
  }
}

MyClass.foo()

позволяет быстро проэцировать имеющий опыт разделения логики и таки уложиться во ВНЕЗАПНЫЙ дедлайн. Почему именно mootools.Class, а не подобие приведенного выше примера или другая реализация? Просто я умею им пользоваться и оно нормально работает.

И так, разделяем логику на экраны:

  • Основной экран - содержит колонку с категориями и провайдерами в категориях

  • Экран ввода реквизитов - обычно это ввод номера телефона или номера договора, или логина/емейла, от чего зависит тип отображаемой клавиатуры - цифровая или буквенная (с русскими/украинскими буквами и английской раскладкой)

  • Экран оплаты - всегда стандартное отображение. Картинка выбраного оператора, сетка комиссии для выбранного оператора, какая-то информация, и реакция на деньги и нажатие кнопки оплатить

Все хорошо. Делаем. Все работает полгода-год. Появляется необходимость показывать (исходя из настроек) экран паркомата первым, а не основной экран. В случае модульной реализации нужно создать класс, по ранее определенным стандартам и в зависимости от настроек сделать не new MainPage(), а new MainParkingPage() и все работает.

Далее, внезапно появляется необходимость принимать не только одно поле для ввода, а два или три, например для платежа на WebMoney нужно спросить еще и номер телефона. Как быть? Архитектура ведь этого не предусматривала... Придется переписывать архитектуру. Если все модульное и с подобием ООП, мы можем определить в настройках вебмани, что теперь отрисовку ввода реквизита будет выполнять другой класс, а в методе реакции на выбор провайдера добавить условие, при котором будет вызываться метод show() у произвольного класса, а не у стандартного. В произвольном же, мы наследуемся от стандартного и дописываем еще один экран перед оплатой. Ничего не ломается, ничего не рефакторится координально.

Собственно, вот. Я благодарен мутулзу за то, как им удалось реализовать привычное ООП в javascript из-за чего я не потратил много времени на рефакторинг по мелочам. Конечно, такого можно достигнуть и используя другие методы разработки, но будет ли это так эффективно, вот что мне хотелось бы обсудить :)

Люблю Python, Django, Android, html5. Занимаюсь платежными инструментами в онлайне и оффлайне.
Подякували: Replace1

4

Re: Prototype VS Classic OOP (JavaScript)

Як захищав так і завжди буду захищати підхід mootools.

JavaScript я люблю. Це моя улюблена мова. Я добре розумію її прототипічну суть. І я добре розумію що таке "ООП" для javascript.

Тут питання зводиться навіть не до використання привичного ООП, а до того що мова то прототипічна, а ви якесь ООП хочете туди всунути.
TheShock правильно написав: там не якесь ООП всунуте, а просто реалізований зручний аліас до прототипів.

Про дискусії на таму "а ваш mootools міняє прототипи нативних об`єктів" я промовчу, так як то трошки виходить за рамки цієї теми.

Сам я вже більше двох років беру участь в обговореннях і т.д. фреймврку mootools. (Хто не знав, там існує закрита група чоловік на 50 до якої входять всі розробники + кілька зацікавлених осіб, як я).

Подякували: mrChex, leofun012

5 Востаннє редагувалося Patron (10.08.2012 10:14:33)

Re: Prototype VS Classic OOP (JavaScript)

пишіть українською мовою! Для чого мені такі пости тут, якщо я на хабрі можу на російські мові почитати? Ну блін, мене це дико дратує.

Щоб зрозуміти рекурсію потрібно спочатку зрозуміти рекурсію.
int fac(int n) { return n < 2 ? 1 : n*fac(n-1); }

6

Re: Prototype VS Classic OOP (JavaScript)

Patron написав:

пишіть українською мовою! Для чого мені такі пости тут, якщо я на хабрі можу на російські мові почитати? Ну блін, мене це дико дратує.

звичайно. Нехай форум залищається пустим. Я в перших рядках написав що не можу об’ємний текст написати українською.

Люблю Python, Django, Android, html5. Занимаюсь платежными инструментами в онлайне и оффлайне.
Подякували: Replace1

7

Re: Prototype VS Classic OOP (JavaScript)

Цей форум україномовний. В цьому його особливість. Російськомовних сотні:
https://www.google.com.ua/search?q=%D1% … 0%BE%D0%B2

Але якщо автору повідомлення важко було висловити свою думку українською мовою, то думаю в цьому немає нічого страшного.

Подякували: koala1

8

Re: Prototype VS Classic OOP (JavaScript)

А шкода що двоє учасників цієї теми зараз не на форумі, бо я страшенно цікавлюсь JavaScript останнім часом... Почав з того що структурую проект за допомогою require.js. Тепер думаю якось застосувати класи. Я їх писав собі за допомогою прототипів (не бачу в прототипах нічого аж такого дикого, в Python об’єкти теж класи, а прототипне успадкування запросто можна зробити рядком:

Y = type('Y', (x.__class__, ), x.__dict__)

Потім я накодив таких евентів за допомогою колбеків, що браузер сказав "to much recursion", після чого я згадав що я десь читав ніби для евентів використовують такий паттерн як PubSub. Почав щось читати, прочитав про Backbone, Spine, всякий інший MVC... І якраз хотів запитати, а чим MooTools відрізняється від інших?

9

Re: Prototype VS Classic OOP (JavaScript)

mrChex написав:

На русском, т.к. удобней излагать объемные мысли именно так.

Є правила. Вони єдині для всіх. Вони вам не подобаються чи незручні - відкривайте тему про це у відповідному розділі; а доки правила такі - будьте ласкаві їх дотримуватися. Бо вам незручна мова, комусь іншому незручна заборона ботів, третьому незручно шукати по форуму і він буде створювати теми, що вже обговорюються...

10

Re: Prototype VS Classic OOP (JavaScript)

Дарма цю тему підняли =)
Принаймі тоді не було в правилах про мову. Вже більше пів року пройшло.

11

Re: Prototype VS Classic OOP (JavaScript)

Ну але це тема не про мову, а про ООП в ній, та інші способи організації коду. :)

12

Re: Prototype VS Classic OOP (JavaScript)

Replace написав:

Дарма цю тему підняли =)
Принаймі тоді не було в правилах про мову. Вже більше пів року пройшло.

Упс... вибачте, не знав.