жирный Switch

[in4core]

Тему назвал так неспроста. Частенько в проектах ( которые мне попадаются) разрабатывается меню, от которого далее зависит весь проект. Объясню каким образом. Рассмотрим аналог онлайн магазина - выбрали товар, сделали с ним операции, добавили в корзину, отправили запрос. Все эти действия происходят с один объектом.
У нас же похожий случай, но маленько отличается. Разделим проект на часть блоков и действий.
1. Мы жмем на меню выбирая какой либо объект
2. От того какой объект выбран создается (добавляется) отдельный класс выполняющий допустим некую функцию обработки.
3. После выполнения 2, создается еще один класс для дальнейшей работы с объектом и снова от того какой объект был выбран происходят действия...
....
и т.д. пунктов может быть много.
В таких проектах мне приходится часто прибегать к switch для проверки выбранного объекта ( естественно кроме switch можно и другие операторы юзать) . И так
Switch 1 - выбрали объект, некоторая переменная ( глобальная) записала название объекта.
Switch 2 - от того что хранит переменная - добавляется класс
Switch 3 - после 2, аналогично
...
и так бесконечно.

__________________________________
Возможно данный пример будет не понятен кому либо, добавлю еще один пример :
Рассмотрим стандартный colorPicker от выборки цвета - у нас зависит дальнейшая работа приложения, после того как приложение завершилось, у нас снова идет проверка на выбранный (изначально) цвет и варианты закрытия программы от него. Сдесь я так же бы использовал два Switch'a
____________________________________________________
И так вопрос, как делаете Вы в таких ситуациях? , и является рациональным такое построение приложения как делаю я со свичами?. Может направите в более правильное русло построения. Спасибо

[expl]

ИМХО смысл размыт. Может на более конкретно один из примеров опишешь?
Вот есть этот colorPicker. Вот мы выбрали цвет. И что дальше произошло?
Что от этого зависит?

[in4core]

Ну вроде не так уж и размыто хорошо попробую пояснить глубже.

1.Выбрали цвет, в public static записали выбранный цвет. ок
2. switch(staticVar) {  case 0xFF: func1(); .........}
3. func1() {  addChild(new Class1()) }
4. ...... приложение отрабатывает
5. Жмем завершить программу  и  switch(staticVar) { case 0xFF: trace('path1') }

Ну вот получилась у нас одна линейность, ну это самый простейший пример из 2х свичей. Тоесть как бы начало и конец имеет общее , но середина это отдельный элемент.

А если рассмотреть посложнее с сотней путей например :
1. Начало приложения switch(Menubtn.text) { case '1': тут работает блок 1 и запускает 10 других блоков}
2. В блоке 5 снова есть switch(Menubtn.text) { ...... } и работа этого блока зависит лишь от выбранной изначально перменной, а не от работы других блоков, он как бы отшельник.

[Psycho Tiger]

Offtop: я нихрена не понял, но в Ваш код мне смотреть будет явно страшно.

[Bgg]

Если я правильно понял, то не устраивает цепочка объектов по сути одинаковых, не? Я обычно в первом меню и создаю конечный объект. Просто этот объект может принимать разные формы.

[expl]

Про цвет ничего не понял, как зависит от выбора цвета выход из программы.

Про меню:
Впринципе, можно и через свитч вызывать нужные функции по тексту меню.
Но, может так проще?

menu.add("show some    picture", showPicture, [pictureUrl]);
menu.add("show another picture", showPicture, [pictureUrl]);
menu.add("about application", showAboutDialog, []);
 
private function showPicture(pictureUrl:String):void {...}
private function showAboutDialog():void {...}
 
class Menu extends Sprite {
    public function add(itemName:String, onClick:Funcion, onClickArguments:Array):void
    ....

P.S. Хочется реально один из твоих свитчей увидеть, во всей красе.
А не слушать рассказы о том какой он из себя и о каких-то переменных.

[in4core]

ща набросаю примерчик побыстрому

[TanaTiX]

Может стоить завести переменную, куда записывать текущий выбранный объект и в зависимости от его свойств (выбранного объекта) дальше разруливать ситуацию? Может даже интерфейсы пригодятся. А вообще солидарен с Psycho Tiger

[in4core]

Имеем класс кнопки состоящий из 4 кадров, на каждом по картинке, где от того какой инстанс выбран на данный момент сохраняется перменная SELECTED.

package classes 
{
	import flash.display.MovieClip;
	import flash.events.MouseEvent;
 
	/**
	 * ...
	 * @author in4core
	 */
	public class MenuBtnMain extends MovieClip 
	{
		public static var SELECTED:String = '';
		public var NAME;
 
 
 
		public function MenuBtnMain() 
		{
 
			this.buttonMode = true;
			this.addEventListener(MouseEvent.CLICK, onClick);
		}
 
		private function onClick(e:MouseEvent):void 
		{
			e.currentTarget._bg.gotoAndStop(2);
			SELECTED = this.NAME;
 
		}
		public function setNameByFrame() {
 
			switch(this.currentFrame) {
				case 1:
				NAME = 'box';
 
 
				break;
				case 2:
				NAME = 'paket';
 
 
				break;
				case 3:
				NAME = 'otk_1';
 
 
				break;
				case 4:
				NAME = 'otk_2';
 
 
				break;
			}
		}	
}

Далее показываю только одну функцию из Main нужную нам
где от того какая кнопка выбрана на данный момент происходят действия с mainMC

private function onClick(e:MouseEvent):void 
		{
 
				mainMC = new BG2();
				addChild(mainMC);
				mainMC.x -= 12;
				mainMC.y -= 35;
				mainMC.setLocation(MenuBtnMain.SELECTED);
 
			}
		}

Ну и стоит показать сам mainMC соотв

public function setLocation(loc:String):void {
			var pat:Patterns = new Patterns();
			addChild(pat);
			pat.x = 20;
			pat.y = 47;
 
			switch(loc) {
				case 'box':
				pat.gotoAndStop(1);
				break;
				case 'paket':
				pat.gotoAndStop(2);
				break;
				case 'otk_1':
				pat.gotoAndStop(3);
				break;
				case 'otk_2':
				pat.gotoAndStop(4);
				break;
			}
 
		}

Данный пример конечно не раскрывает всю суть вопроса, но он более менее ее объясняет, сдесь конечно кадры кнопки равны кадрам pat , поэтому можно тупо сохранять номер кадра а не название, а вот если они не то что не равны, а даже не подчиняются мат законам, тогда вот такую конструкцию приходится делать полюбому, или нет?! Надеюсь так понятнее

[andrew911]

Паттерны State/Strategy?
http://johnlindquist.com/2010/08/31/...state-pattern/
http://johnlindquist.com/2010/08/25/...ategy-pattern/