19.03.2009, 18:54
|
Аспирант
|
|
Регистрация: 20.08.2008
Сообщений: 56
|
|
Нет, у меня цель немного другая.
Грубо говоря объект A сейчас создается один раз и затраты на его создание сейчас большого значения не имеют. А вот объекты типа B будут создаваться регулярно и затраты на их создание мне надо максимально уменьшить. Т.е. минимализировать количество процедур в объекте B и аргументов передаваемых в объект A.
Т.е. надо усложнять объект A, для того чтобы максимально упростить вызов его методов из объектов B. Так-же не будет проблемой если мы усложним конструктор объекта B.
В конце концов, можно добавить какие-то вспомогательные методы в прототип P, через которые я буду оброащаться к объекту A. Но это решение мне уже не нравится, т.к. будет вызывать путаницу. В этом случае уже лучше будет заставлять передавать this, через аргументы.
И в последнем примере у Вас опять this внутри метода объекта A содержит ссылку на "чужой" объект. Меня это решение не устраивает.
Последний раз редактировалось no_alex, 19.03.2009 в 18:59.
|
|
19.03.2009, 19:03
|
|
Матрос
|
|
Регистрация: 04.04.2008
Сообщений: 6,246
|
|
чем вам вариант сделать A прототипом объектов B не подходит?
если вам нужен самостоятельный прототип у объектов B, то тогда делаем P прототипом объектов B, а A в свою очередь пусть будет прототипом объекта P
|
|
19.03.2009, 19:12
|
Аспирант
|
|
Регистрация: 20.08.2008
Сообщений: 56
|
|
Увы, все не так просто...
Я чуть позже напишу пример того как я пытался решить эту задачу. Но тот пример будет не рабочий. В нем каждый повторный созданный объект затирает предыдущий. Но возможно Вы подскажете как можно в моем примере эту проблему "разрулить".
Если не возражаете, давайте прервем это обсуждение на пару часиков, или, если удобно - до завтра.
|
|
19.03.2009, 19:16
|
|
Матрос
|
|
Регистрация: 04.04.2008
Сообщений: 6,246
|
|
no_alex,
та мне-то удобно вообще не решать вашу проблему:wacko:
жду вашего примера. обсудим-попробуем
когда вам удобно, тогда и выкладывайте
|
|
19.03.2009, 19:36
|
Профессор
|
|
Регистрация: 25.02.2008
Сообщений: 707
|
|
Сообщение от Kolyaj
|
Ему нужно реализовать паттерн делегатор. Если бы его можно было в js реализовать, я бы бед не знал
|
JS и так полностью пропитан делегированием. И реализовать именно паттерн "Делегатор" не преставляет труда (что мешает вызвать из a.test() b.test() ?).
Всё-таки, у doesNotUnderstand (Smalltalk), method_missing (Ruby) / __call (PHP), __noSuchMethod__ (JS in Firefox) и т.д. другая цель - выставить последнюю "точку обороны", когда объект (просмотрев всю цепь наследования) не может ответить на сообщение (точно так же, как будто мы открыли неправильный URL - браузер же, всё-таки, отреагировал, выдав нам соотвествующее сообщение). А делегировать или нет в этом методе к другим объектам - это дело десятое.
Последний раз редактировалось Dmitry A. Soshnikov, 19.03.2009 в 19:47.
|
|
19.03.2009, 20:08
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от Dmitry A. Soshnikov
|
что мешает вызвать из a.test() b.test() ?
|
То, что test может быть любым.
|
|
19.03.2009, 21:02
|
Профессор
|
|
Регистрация: 25.02.2008
Сообщений: 707
|
|
Сообщение от Kolyaj
|
То, что test может быть любым.
|
? Ниче не понял =) В паттерне "Делегатор" описывается метод, который вызывает (такой же) метод объекта-делегатора (который может меняться динамически).
В любом случае, __noSuchMethod__ (и иже с ними) тут не при чём (паттерна "Делегатор" это может коснуться только косвенно, т.к. объект может и не делегировать ни к кому, а выполнить какой-нибудь свой другой метод).
|
|
19.03.2009, 21:20
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от Dmitry A. Soshnikov
|
Ниче не понял =) В паттерне "Делегатор" описывается метод, который вызывает (такой же) метод объекта-делегатора (который может меняться динамически).
|
И все прекрасно, пока мы знаем имена всех методов, которые могут быть вызваны. Есть у нас допустим объект А, и мы хотим создать для него делегатор Б, который будет как-то изменять вызов некоторого множества методов, а остальные методы должны остаться без изменений. Например, обертка для DOM-узла, которая определяет свои методы, а родные, точнее неопределенные в ней, делегирует DOM-элементу. Такое нереально написать в JS, т.к. руками все методы переписывать нереально и нецелесообразно, а метода а-ля __call нет.
|
|
19.03.2009, 21:25
|
Профессор
|
|
Регистрация: 25.02.2008
Сообщений: 707
|
|
Сообщение от Kolyaj
|
И все прекрасно, пока мы знаем имена всех методов
|
Это и есть паттерн "Делегатор".
Сообщение от Kolyaj
|
__call
|
А это - обработка события, когда объект не может ответить на сообщение (и как очень частный случай здесь может быть делегация).
Сообщение от Kolyaj
|
Такое нереально написать в JS
|
Еще раз - под FF - пожалуйста:
var a = {
__noSuchMethod__: function (id, args) {
alert('Called: ' + id + ', args: ' + args);
}
};
a.test();
a.test2(1, 2, 3);
|
|
19.03.2009, 21:54
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от Dmitry A. Soshnikov
|
Еще раз - под FF - пожалуйста:
|
Написать на JS === должно работать везде, где есть JS.
|
|
|
|