глобальные или локальные обьекты

[nerv_]

один объект - компонент ... это такая элементарная частица, на которую ты разбиваешь задачу.

результат - дом, который надо построить, функции/объекты - кирпичи

при использовании ООП кода пишется в несколько раз больше, чем при декларативном программировании.

для тупых что такое

декларативном программировании

вики смотрел, не понял. Пример. (типа это от слова объявлять)

Синглетоны там разместить можно, обьекты вроде конфигов, но неболее.

внутренние механизмы app

модели в MVP

пока даже не касался )

По сути одни и теже "кролики", но с разными ушами)

+ последний кролик с пятой ногой (добавляется метод)

Но что если моему приложению нужен всего один кролик(который умеет прыгать), а еще нужна, например, черепаха - которая умеет ползать?

если у них есть что-то общее - звери/млекопитающие, выделяешь это и используешь

И зачем для одного кролика нужна фабрика для создания кроликов?

выше я дал тебе ссылку на книгу. Фабрики - один из шаблонов. Шаблонов много. Например, в моем коде присутствует итератор. найдешь? )

Кстати что делает ваш код?

парсит, заключает в теги -> подсвечивает

[dmitry111]

melky,

декларативном программировании
вики смотрел, не понял. Пример. (типа это от слова объявлять)

думаю это построение кода с использованием Function Declaration и их объявлением

выше я дал тебе ссылку на книгу. Фабрики - один из шаблонов. Шаблонов много. Например, в моем коде присутствует итератор. найдешь? )

да, есть такая книжка, как раз взялся за ее изучение

[melky]

что такое

думаю это построение кода с использованием Function Declaration и их объявлением

всё очень просто : в коде вы описываете решение задачи, а не решаете её.

пример : сложить 2 числа - 4 и 6.

императивное (сюда же я отнёс ООП):

4 + 6; // решили

декларативное:

/* применит оператор "+" к аргументам */
function sum (a,b) { return a + b; }

sum(4, 6); // решение задачи - сложение (вызов функции сложения) чисел 4 и 6.

те же кирпичики, только они могут гнуться, как резина

всё идёт веселее, когда появляются функции, обеспечивающие подобие лямбда-вычислений на функциях - тогда правда весело писать код и задача решается элегантно и красиво... но эти кирпичи тормозят

[Gozar]

императивное (сюда же я отнёс ООП)

Нельзя ли пояснить?

Насколько я понимаю ООП относиться к структурному программированию. А ты его уровнял с процедурщиной.

[melky]

Насколько я понимаю ООП относиться к структурному программированию. А ты его уровнял с процедурщиной.

ну, я имел в виду не сами объекты, а код в их медотах.

[DjDiablo]

я был огорчён производительностью приложения на декларативщине

присоеденяюсь к вопросу. Насколько я помню цикл быстрее рекурсии, а замыкания порядочно занижали а вероятно и сейчас занижают скорость исполнения, так что откуда прирост непонятно.

З.Ы.
Небольшая заметка для новичков. Нельзя всё программирование свести к борьбе за скорость, скорость критична в компьютерных играх или рендерах каких либо графических приложений. Но в подавляющем числе задач скорость имеет значительно меньшее значение, и бороться за миллисекунды нет ни какого смысла. К примеру обсолютно пофиг с какой скоростью готовится отчёт по деятельности предприятия, лишние 100 или 200 мс погоды не делают. Здесь более важно то насколько этот отчёт можно удобно менять вслед за тем как изменяется бизнес. То есть критерии оценки качества продукта совершенно иные.

[dmitry111]

Вот сделал небольшой сприпт с использованием ООП, покритикуйте (я еще в этом новичок):
http://jsbin.com/egevaf/1/edit

Можно ли как-то улучшить, что-то изменить или вообще удалить.. Хочется увидеть безупречный код реализации задачи)

Скрипт добавляет обработчики к элементам li и создает новые элементы li. При наведении на элемент - показывается текст.

Спасибо!

[DjDiablo]

Не забывай о серверах и прочих потенциально высоконагруженных приложениях.

незабываю, перечислять все примеры просто неохото )))
в целом согласен.

Вот сделал небольшой скрипт с использованием ООП.

Вынес методы в прототип, сделал несколько свойств-переменных в объекте, ну в принципе всё верно
Однако с точки зрения применения всего этого в реальности, получается полный Бред.

Абсолютно бессмысленное использование объектов, все методы объекта вызываются из конструктора и больше неоткуда, они даже не наследуются не кем и немогут быть кем либо переопределены. Спрашивается на хрен тогда вообще нужен объект, если со свойствами обьекта попросту нечего делать ?????

На самом деле ты написал вот ЭТО http://jsbin.com/olojol/1/edit
Просто написал это через задницу . Мне нечем оправдать использование объектов в твоём примере.
Вот такие дела чувак. В целом код хороший, но совершенно неуместный

Доведи пример до уровня в котором появится необходимость в ООП, тогда и поговорим про ООП.

[melky]

А можно поподробнее, что конкретно замедляло исполнение кода и на каких движках? (мне особенно интересно, если это относится к V8)

замедляли врапперы вызовов... сейчас покажу примерчик (git всё помнит, хехе)

+    /**

+     * Просто вызовет функцию с аргументами

+     * @param {Function} func функция

+     * @param {Array=} args массив аргументов

+     * @param {Object=} ctx контекст

+     * @return {*}

+     */

+    function apply (func, args, ctx) {

+        return type.function(func) && func.apply(ctx, args);

+    }

+

+    /**

+     * Вернёт функцию, которая применит список функций,

+     * до тех пор, пока они будут возвращать истинное значение

+     * при переданных аргументах

+     *

+     * альтернатива : f(x) && g(x) && ...

+     *

+     * @param {...Function} functions список функций

+     * @return {Function}

+     */

+    function and (functions) {

+

+        functions = slice(arguments);

+

+        return function (/* args */) {

+            var args = arguments;

+            return each(functions, function (func) { return toBool(apply(func, args)); });

+        };

+    }

+

+    /**

+     * Частичное применение функции

+     * Аргументы можно пропускать, передав

+     * специальное значение "_"; при запуске

+     * пропущенные аргументы заполнятся

+     * слева направо.

+     *

+     * @param {Function} fn функция

+     * @param {Array} args аргументы

+     * @param {Object=} ctx контекст исполнения функции

+     * @return {Function} частично применённая функция

+     *

+     * @example

+     * var line = function (k, x, b) { return k * x + b; };

+     * var id = partial(line, [ 1, _, 0 ]);

+     * id(0);   // 0

+     * id(2);   // 2

+     * id(777); // 777

+     */

+    function partial (fn, args, ctx) {

+

+        function isHole (x) { return x === partial.hole; }

+

+        return function () {

+

+            var fresh = new Iterator(arguments);

+            fresh.none = partial.defaultValue;

+

+            function filter (arg) { return isHole(arg) ? fresh.next():arg; }

+

+            return apply(fn, map(args, filter).concat(slice(fresh.collection, fresh.index)), ctx);

+        };

+    }

+

+    /**

+     * Вернёт функцию, которая передаст первой функции только

+     * указанное количество аргументов

+     * @param {Function} fn

+     * @param {number} num

+     * @return {Function}

+     */

+    function aritilize (fn, num) {

+        return function() {

+            return fn.apply(this, slice(arguments, 0, num));

+        }

+    }

+

+    /**

+     * Обратит порядок аргументов у функции

+     * @param {Function} fn

+     * @param {Object=} ctx Контекст исполнения

+     * @return {Function}

+     */

+    function reverse (fn, ctx) {

+        return function () {

+            apply(fn, slice(arguments).reverse(), ctx);

+        };

+    }

+

+    /**

+     * Аналог bind из ES5. Формат

+     * аргументов, как в partial

+     * @inheritDoc

+     * @see partial

+     */

+    function bind (fn, ctx, args) { return partial(fn, args || [], ctx); }

+

+    /**

+     * Значение для любого аргумента по-умолчанию

+     * @type {undefined}

+     * @private

+     */

+    partial.defaultValue = undefined;

+

+    /**

+     * Специальное значение "дырка", указывающее на то,

+     * что аргумент пропущен

+     * @type {Object}

+     * @private

+     * @see partial

+     */

+    var _ = partial.hole = {};

+

+    /**

+     * Вернёт функцию, которая последовательно

+     * применит список функций к аргуметам

+     *

+     * Альтернатива: f(g(x))

+     *

+     * @param {...Function} functions список функций

+     * @return {Function}

+     */

+    function compose (functions) {

+

+        functions = slice(arguments);

+

+        return function (/* args */) {

+            var args = slice(arguments);

+            each(functions, function (func) { args = [ apply(func, args) ]; });

+            return args;

+        };

     }

с помощью них можно было писать красивый декларативный код... но в профилировщике на первом месте висел не код приложения, а код этих врапперов.

код написал на вдохновении после прочтения книжки о лямбда-исчислении

присоеденяюсь к вопросу. Насколько я помню цикл быстрее рекурсии, а замыкания порядочно занижали а вероятно и сейчас занижают скорость исполнения, так что откуда прирост непонятно.

З.Ы.
Небольшая заметка для новичков. Нельзя всё программирование свести к борьбе за скорость, скорость критична в компьютерных играх или рендерах каких либо графических приложений. Но в подавляющем числе задач скорость имеет значительно меньшее значение, и бороться за миллисекунды нет ни какого смысла. К примеру обсолютно пофиг с какой скоростью готовится отчёт по деятельности предприятия, лишние 100 или 200 мс погоды не делают. Здесь более важно то насколько этот отчёт можно удобно менять вслед за тем как изменяется бизнес. То есть критерии оценки качества продукта совершенно иные.

согласен полностью.. жаль, что в текущем скрипте она действительно важна, и от скорости его зависит многое.

[Gozar]

Вот сделал небольшой сприпт с использованием ООП, покритикуйте

Мне не понравилось вот это:

add.onclick, item.onmouseover ...

https://developer.mozilla.org/ru/doc...dEventListener

show и hide можно объединить в визибилити:

Unit.prototype.Visibility(item, showHideFlag)

Не понравилось вот это:

items[i] = new Unit(items[i].getAttribute("data-text"), items[i]);

Больше подходит для тестов, чем для нормального кода.

Использование реги считаю неоправданным, покрайней мере можно не выносить её в переменную и вообще разбить по

.split(/[.!?]/)[0]

Правда можно вынести её в метод и назвать его getFirstSentence

Реги нужно отделять от вызова только если они многократно используются иначе их неудобно искать в коде и не ясно, что происходит в этом месте. Но это ИМХО.

В остальном мне такой подход нравиться гораздо больше, чем DjDiablo, т.к. он правильно допиленный легко расширяем без потери читабельности кода.

Мне важно, чтобы я мог быстро расширить любой код и не ломать голову мотая скролл по текущей функции в поисках подфункции, когда можно её вынести в метод. Каюсь, сам иногда делаю подфункции, но стараюсь делать это редко.