глобальные или локальные обьекты
Доброго времени суток!
Немного не пойму, как предпочтительнее организовать пртранство имён: Использовать 1 глобальный обьект, в свойствах которого будут находится другие обьекты? Или сделать инициализирующую функцию, в которой будут обьявлятся нужные обьекты и функции? |
Смотря для чего.
Если у тебя библиотека, то без глобального объекта ты не обойдешься, иначе к нему не будет доступа. Код в студию. |
Цитата:
Кажись врубился |
обычно есть два глобальных обьекта играющие роль неймспейсов
На примере ExtJs Неймспейс для фреймворка Ext Неймспейс приложения app На прмере jQuery фреймворк/плагины в $ Неймспейс приложения в app других глобальных переменных нет, совершенно нет, ни разу. в app стоит описывать классы, а вот экземпляры классов пихать в обьект неймспейса app крайне нежелательно. Передавайте экземпляры, через конструктор, функции. Где возможно старайтесь свести обмен между компонентами к обмену сообщениями, не прибегая к передачи ссылок на обьекты |
вот я уже много месяцев изучаю и много литературы прочитал про ООП.
Я знаю что и как работает, но не знаю где и как это можно применить( Создать приложение используя объекты это еще осуществимо и понятно. Приложение похоже на дерево, состоящее из веток (модулей). Но для чего нужна функция-конструктор и зачем создавать с помощью нее объекты, зачем наследовать возможности одного объекта другим? Мне кажется это можно задействовать в разработке библиотеки или фреймворка, когда над каким-то элементом осуществляются определенные действия (jquery) Об протопипах, функции-конструкторе пишут везде, мне поначалу казалось что это главная сущность js-кода, сейчас мне начинает казаться что это просто фича, которая при неправильном использовании приведет к еще большей путанице в коде. А классы. Зачем они нужны? Все пишут в js нет классов, но можно их создать - получится убого, зато как в JAVA Может быть я не прав, у меня нет опыта в работе c другими языками( Буду рад если переубедите меня Как строить приложения используя все полезности ООП? Может есть какие-нибудь алгоритмы? |
l-liava-l,
удобно создать один глобальный объект, тогда все модули можно будет размещать в отдельных файлах и подключать по мере надобности |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
nerv_,
благодарю за пример, я по нему пробежался - есть функция конструктор - formula.Unit. Она создает объекты и наделяет их одинаковыми методами и разными свойствами. По сути одни и теже "кролики", но с разными ушами) Но что если моему приложению нужен всего один кролик(который умеет прыгать), а еще нужна, например, черепаха - которая умеет ползать? Создавать новый контруктор для черепахи? И зачем для одного кролика нужна фабрика для создания кроликов? Это я к тому, что, по моему опыту, чаще всего в "зоопарк" приложения требуются животные в единственных экземплярах (возможно я не прав - опыт небольшой :) ) Кстати что делает ваш код? |
Цитата:
собственно пример как можно связать контролёры и модели в MVP, тут реализовано сразу два подхода, app.Model является доступной сразу для двух контролёров в тоже время у каждого контролёра есть своя модель. профит при исчезнавении контролёра модель исчезнет вместе с ним, к томуже неймспейс незахламлён посторонним мусором и содержит только классы. Это неединственный подход, есть и другие которые мне нравятся неменьше.
//абстрактные классы с общим для всех контролёров функционалом
class("app.Controlller",{
//бла бла
})
// модель
class("app.Model",{
//бла бла
})
//реальные классы экземпляры которых мы будем создавать
//контролёр1
class("app.controller1",{
extend:"app.controller",
init:function(param){
//ссылка на модель
this.model1=param.model;
//экземпляр модели существующий только внутри контролёра
this.model2=app.myModel1({
});
}
//бла бла
})
//контролёр2
class("app.controller2",{
extend:"app.controller",
init:function(param){
//ссылка на модель
this.model1=param.model;
//экземпляр модели существующий только внутри контролёра
this.model2=app.myModel1({
});
}
//бла бла
})
//модель
class("app.myModel",{
extend:"app.Model"
//бла бла
})
//модель для внутреннего использования в классе контроллер 1
class("app.myModel1",{
extend:"app.Model"
//бла бла
})
//модель для внутреннего использования в классе контроллер 2
class("app.myModel2",{
extend:"app.Model"
//бла бла
})
//в этой функции инициализируется приложение
$(function(){
// общая модель для двух контролёров
var myModel= new app.myModel({
//инициализация
});
// контролёр 1
var contr1 = new app.controller1({
model: myModel
})
// контролёр 2
var contr2 = new app.controller2({
model: myModel
})
})
|
Цитата:
к примеру, нужно сделать игру арканоид. ты разбиваешь "игру" на "полоску, от которой отражается мячик", "мячик", и "блоки", и "физический мир" (это движок, обрабатывающий всё происходящее, столкновения , например) и вот для всех этих частей ты создаёшь классы (я так называю конструктор + прототип) мячик, как известно, может быть огненным, или ещё каким-нибудь. то, что создан объект "мячик", говорит расплывчато о том, что он вообще есть. нужно уточнить его понятие. для этого ты создаешь класс "огненный мячик", который наследует "простой" - т.е. добавляет новые свойства\методы. таким образом, каждый класс является либо уточнением (расширением) или же составляет какую-либо элементарную единицу приложения, как и все тела разделяются на атомы. Цитата:
при использовании ООП кода пишется в несколько раз больше, чем при декларативном программировании. а оптимизация относится только к корявости реализации функций в JS (я был огорчён производительностью приложения на декларативщине.... хотя, может нужно было прогнать в GCC advanced mode и заинлайнить всё, что можно...) |
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
melky,
:thanks: Цитата:
Цитата:
|
Цитата:
Цитата:
пример : сложить 2 числа - 4 и 6. императивное (сюда же я отнёс ООП): 4 + 6; // решили декларативное:
/* применит оператор "+" к аргументам */
function sum (a,b) { return a + b; }
sum(4, 6); // решение задачи - сложение (вызов функции сложения) чисел 4 и 6.
те же кирпичики, только они могут гнуться, как резина :) всё идёт веселее, когда появляются функции, обеспечивающие подобие лямбда-вычислений на функциях - тогда правда весело писать код и задача решается элегантно и красиво... но эти кирпичи тормозят :) |
Цитата:
Нельзя ли пояснить? Насколько я понимаю ООП относиться к структурному программированию. А ты его уровнял с процедурщиной. |
Цитата:
|
Цитата:
З.Ы. Небольшая заметка для новичков. Нельзя всё программирование свести к борьбе за скорость, скорость критична в компьютерных играх или рендерах каких либо графических приложений. Но в подавляющем числе задач скорость имеет значительно меньшее значение, и бороться за миллисекунды нет ни какого смысла. К примеру обсолютно пофиг с какой скоростью готовится отчёт по деятельности предприятия, лишние 100 или 200 мс погоды не делают. Здесь более важно то насколько этот отчёт можно удобно менять вслед за тем как изменяется бизнес. То есть критерии оценки качества продукта совершенно иные. |
Вот сделал небольшой сприпт с использованием ООП, покритикуйте (я еще в этом новичок):
http://jsbin.com/egevaf/1/edit Можно ли как-то улучшить, что-то изменить или вообще удалить.. Хочется увидеть безупречный код реализации задачи) Скрипт добавляет обработчики к элементам li и создает новые элементы li. При наведении на элемент - показывается текст. Спасибо! |
Цитата:
в целом согласен. Цитата:
Однако с точки зрения применения всего этого в реальности, получается полный Бред. Абсолютно бессмысленное использование объектов, все методы объекта вызываются из конструктора и больше неоткуда, они даже не наследуются не кем и немогут быть кем либо переопределены. Спрашивается на хрен тогда вообще нужен объект, если со свойствами обьекта попросту нечего делать ????? На самом деле ты написал вот ЭТО http://jsbin.com/olojol/1/edit Просто написал это через задницу :). Мне нечем оправдать использование объектов в твоём примере. Вот такие дела чувак. В целом код хороший, но совершенно неуместный :) Доведи пример до уровня в котором появится необходимость в ООП, тогда и поговорим про ООП. |
Цитата:
+ /**
+ * Просто вызовет функцию с аргументами
+ * @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;
+ };
}
с помощью них можно было писать красивый декларативный код... но в профилировщике на первом месте висел не код приложения, а код этих врапперов. код написал на вдохновении после прочтения книжки о лямбда-исчислении :) Цитата:
|
Цитата:
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, т.к. он правильно допиленный легко расширяем без потери читабельности кода. Мне важно, чтобы я мог быстро расширить любой код и не ломать голову мотая скролл по текущей функции в поисках подфункции, когда можно её вынести в метод. Каюсь, сам иногда делаю подфункции, но стараюсь делать это редко. |
Цитата:
|
Цитата:
|
Цитата:
если влом использовать модули, то глобальные обьекты |
Цитата:
|
Цитата:
mySuperLib.DOM = (function () {
var myObj = {};
return myObj;
})();
|
Цитата:
на клиенте полно велосипедов на выбор, но лучше выбрать с компиляцией на сервере. сам пользуюсь этим https://github.com/vflash/scmod |
Цитата:
Цитата:
|
Цитата:
|
| Часовой пояс GMT +3, время: 02:53. |