MVC: грамотная архитектура проекта

[Akopalipsis]

elder_Nosferatu если бы эти посты написал кто то другой Вы бы все равно эти слова сказали?
Тогда идите в соседнею тему и напишите, что я Вам поддакиваю! А то я там сказал, что Вы хороший вариант предложили, который я опробовал.

[elder_Nosferatu]

Да Wolsh`а я уважаю, особенно за его терпение к непонимающим (истинный педагог). Но не его авторитет меня вдохновил, а мысли, которые он выдал! И я не сразу проникся его словами. По началу я даже пытался вести с ним спор, который прекратили мои оффлайновые дела. Но сегодня внимательно перечитывая эту тему я прозрел.
Когда я только открывал эту ветку я этому подходу не радовался, потому что неправильно его использовал. У меня модели были слишком умными и пытались быть в курсе всех мелочей. По этому виды постоянно рапортовали о своих действиях. Wolsh же показал мне что модели нужно абстрагироваться от мирской суеты. А виды должны максимально обрабатывать свои личные данные и рапортовать только о результате.
Например мой переезд: Вызвали мы грузовик и начали бегать с вещами с 5-го этажа на первый. Тот еще ВИД был! Пакеты с одеждой, коробки с книгами и посудой, два компа и торчащие провода, мебель в конце концов. А шоферу грузовика плевать. Он ни разу не спросил, долго ли еще, помочь ли нам - он просто стоял в сторонке, покуивал сигаретку и ждал команды "Все, поехали!". Та же ситуация повторилась и во время разгрузки.
А был еще мой приятель, которого я взял себе в подмогу. Он постоянно меня спрашивал "что теперь нести?", "а на какой этаж потом выносить?", "где можно руки помыть?" и т.д. В конце концов и водила и кореш справились с поставленой задачей, но с первым я почти не разговаривал, а второму постоянно приходилось отвечать (даже тогда, когда набрав в грудь воздуха взалил на себя кусок разобраного трюмо и говорить было неудобно). К тому же дружбан мой возвращался домой чрез пол города в испачканом спорт-костюме, а у водилы разве что брюки сильнее помялись от сидения.
Вряд ли пример хороший, но... я старался

Добавлено через 10 минут
Блин, дописал, отправил и только потом до меня дошло: Вы наверное обиделись, на мой смайлик, подумав, что я о Вас написал... А я то думал, что Вас интересовал мой первый пост за сегодня. Я решил, что Вы меня подозреваеете в том, что яподлизываюсь к Wolsh`у...

На самом деле тот текстовый "смайл" был ответом на Ваш пост #117. И значил он "Я хотел Вам ответить, но Wolsh меня опередил и дал развернутые объяснения, так что мне ничего не осталось, кроме как согласиться. А так, как Ваш вопрос был адресован мне, то не ответить, было бы неприлично."

Добавлено через 11 минут
А я всегда говорил, что общение смайлами невыразительное и сухое. Сам же на этом и попался :/

[Akopalipsis]

Вы наверное обиделись, на мой смайлик, подумав, что я о Вас написал...

я не капельки не обиделся, но да!) я принил их на свой счёт)) сорри)

И я не могу себе позволить не возвратится к теме - сегодняшний день худо - бедно да принёс плоды, очень рад, что напрямую указали, что наблюдатель, это тот же диспетчер. Сам я хоть и увидел схожесть, но не отказался бы от его использования только по тому, что ведь так в книжках написано. Но не могу я не спросить - это действительно так?
Потому что, получится, что много однотипных методов будут обработчиками. Например метод init, update, restart и т.п. будут обработчиками событий и ждать будут одноимённой константы. И при переносе этого класса в другое приложение обяжет использование тех же констант. Вроде не чего страшного, но если у всех классов есть слушатель restart, то придется делать констант для каждого класса.
Вот опытные используют слушателя или событиями кидаются?

[Babylon]

вам пора баиньки

[elder_Nosferatu]

Во первых ожидается не константа, а строка - будет она сохранена в константе, переменной или просто записана, как литерал - без разници. Так что если Вас напрягает писать Event.COMPLETE, то можете просто указать значение этой константы - "complete". Но эти константы не зря придумали. Помимо их прямого назначения, как констант, они еще несут в себе функцию подсказки. Если Ваш IDE поддержывает автозаполнение, тогда он Вам и подскажет точное название константы по первых буквах. Но если вместо константы вы будете набирать литерал "complete", тогда у Вас больше шансов сделать оЧЕПятку.

Еще в пользу констант. Обратите внимание на константы "родных" событий. Все они сохранены, как статические члены класса самого события, а значит используя это событие (читай импортируя класс события в приложение) Вы вместе с ним тянете и константы его типов. Так что не использовать эти константы просто глупо.

Также замечу, что заявленые константы типов никак не ограничивают набор возможных событий. Они носят только информативно-вспомогательный характер. Так что можно спокойно разослать событие класса Event с типом "oops_I_did_it_again". Беда только, что стороннему человеку будет сложно догадаться без подсказки, что такого события можно ожидать.

На счет личных событий. Если экземпляры Вашего класа хотят рассылать события, то не стоит спешить создавать для этого класса собственный класc событий. Можна использовать одно из стандартных событий. А если оно будет не достаточно информативным, тогда стоит создать свой класс события с необходимыми свойствами для хранения той инфы, которая должна передаваться с событем. Например универсальное событие Event. Его использует множество классов - события и сцены и редактирования текста и конец звука и смены кадров и т.д. и т.п. Но каким бы полезным не был класс Event, его информативности не хватает для клавиатуры. Вот для нее уже создали свое событие, которое предоставляет больше информации. Короче суть в том, что перед тем, как ваять свой класс события, следует думать не о том, кто его собирается рассылать, а о самом событии (не о классе, а о... явлении, что ли?). Хорошим примером будет MouseEvent. Его рассылает целая свора ИнтерактивныхОбъектов, но класс назвали не SpriteEvent, не ButtonEvent, не TextFieldEvent, и даже не InteractiveEvent, а MouseEvent. Интересно то, что класс Mouse (которому, по незнанию, можно было бы приписывать события класса MouseEvent) не наследует EventDispatcher, а значит его экземпляры и не могут рассылать события. Он вообще не имеет ничего полезного, кроме статических членов (его екземпляры ничем не будут отличаться от Object).

Упомяну еще две "хитрости". Полезного в них мало, но они помогут точнее понимать происходящее. Это как с Истиной. Человек, говоря Правду, расказывает Истину, но ставит акценты на то, что считает важным, тем самым уменьшает значение остального, превращая его в "тонкости" и "нюансы". Этим "грешат" все авторы, но...
Итак:
#1: Регистрируя обработчик события, EventDispatcher принимает ссылку на функцию. Никто не запрещает для нескольких событий использовать один обработчик. Для чего?
Вариант 1: когда я пишу класс кнопки, мне нужно запрограмировать ее поведение. Не знаю, как у кого а мои кнопки, будучи нажатымы, возвращаются в исходное положение, когда я их отпускаю и когда убираю с них курсор (даже если LMB все еще зажата). А значит я использую один обработчик для событий "mouseUp" и "rollOut".
Вариант 2: чтобы не плодить кучу методов-обработчиков я делаю все в одном единственном. Метод сомнительный, но возможность такая есть.

var btn:MyButton = MyButton();
btn.addEventListener(MouseEvent.CLICK, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_UP, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_DOWN, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_MOVE, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_OVER, mouseHandler);
btn.addEventListener(MouseEvent.MOUSE_OUT, mouseHandler);
function mouseHandler(event:MouseEvent):void {
	switch (event.type) {
		case MouseEvent.CLICK		: /* do click */ break;
		case MouseEvent.MOUSE_UP	: /* do up */	 break;
		case MouseEvent.MOUSE_DOWN	: /* do down */	 break;
		case MouseEvent.MOUSE_MOVE	: /* do move */	 break;
		case MouseEvent.MOUSE_OVER	: /* do over */	 break;
		case MouseEvent.MOUSE_OUT	: /* do out */	 break;
	}
}

#2:Функция-обработчик ожыдает не столько экземпляр определенного класса, сколько какой-нибудь объект. Следовательно она справится с любым из наследников класса Object. Например, если Вас не интересуют детали события класса MouseEvent(ну там delta, altKey, ctrlKey, shiftKey, localX, stageY...), а всего лишь факт самого события, то в обработчике события можна запрашивать не MouseEvent, а его предка (Event или Object). Спросите "Зачем?" Я без понятия. Спросите "Сработает ли?" 100-пудово! Сам проверял.

var btn:MyButton = MyButton();
btn.addEventListener(MouseEvent.CLICK, clickHandler);
btn.addEventListener(MouseEvent.MOUSE_MOVE, moveHandler);
function clickHandler(event:Object):void {
	trace("Oops...");
}
function moveHandler(event:Object):void {
	trace("LOCAL POS:", event.localX + ", " + event.localY);
}

Все, пошел спать!

[Akopalipsis]

elder_Nosferatu Спасибо! Всё знал кроме последнего, возможно когда то пригодится.
А я пойду лазить в поисках информации об архитектуре, потому что как мне кажется, эта тема уже под грифом секретности.

[Akopalipsis]

Мне кажется ты не совсем понимаешь суть наследования.

требуется немного уточнения, Вы ведь так строите структуру?
То есть есть базовый абстрактный класс от которого наследуется главный класс одного из фигурантов MVC.
Так этот супер фигурант содержит ссылки на все суб классы, которые так же как и супер класс, наследуются от базового класса. А вот дети суб классов наследуются уже от кого хотят. Вы так делаете?

[AlexLucas]

Читаю и сразу же появляются вот такие ассоциации

[Akopalipsis]

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

[Dukobpa3]

Кривая диаграмма слегка.
На самом деле как-то так:

Но МейнМодель и МейнВью могут создаваться в МейнКонтроллере.
На моей схеме они все втроем создаются в точке входа.

//UPD
Увидал косяк. В легенде перепутал супер с чилдом, там наоборот, стрелочка указывает в супер-класс. Картинку перерисовывать не буду сейчас.