Обращение к родителю

[IDimitry]

Насколько понял, речь идет не о породившем и порожденном классах, а о классах в иерархии флеш-документа и их взаимотношении.

[etc]

Сообщение от IDimitry

Насколько понял, речь идет не о породившем и порожденном классах, а о классах в иерархии флеш-документа и их взаимотношении.

А какая разница?

[IDimitry]

В первом случае создаем класс-прототип, от которого порождены другие классы - к примеру, однотипные элементы для сцены. Класс-родитель предоставляет какие-то общие для потомков свойства и методы. Связь родитель-потомок есть, но смысла обращаться к родителю ну никакого нет - что мы там забыли?

Второй случай лучше всего видно в ситуации, которая возникает буквально у каждого: есть главный паблиш класс, без которого не обойтись, и классы элементов, расположенные на сцене. При обращении из класса элемента к главному классу (если они MovieClip или Sprite) происходит через parent. Но с точки зрения ООП какой же он парент? - Он овнер. И избежать взаимодействия между такими зависимыми классами невозможно (не представляю ситуацию, когда можно было работать только с "черными ящиками").

А если зависимый класс не от Sprite (MovieClip)? - Прямой связи нет. Как уже писали, для обращения из "потомка" к "родителю" приходится передавать экземпляр последнего. Конечно, для архитектуры ущербно, но иногда без этого никак ...

[Smrad]

Сообщение от IDimitry

А если зависимый класс не от Sprite (MovieClip)? - Прямой связи нет. Как уже писали, для обращения из "потомка" к "родителю" приходится передавать экземпляр последнего. Конечно, для архитектуры ущербно, но иногда без этого никак ...

Для нотификации лучше использовать сообщения.

[etc]

IDimitry, я во всём нашем проекте (1300+ классов) нашёл единственное место, было обращение к родителю. И то, просто лишь потому что было лень и некогда сделать нормально.

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

[xpymbl4]

Хорошо. Т.е., напимер, способ описанный ниже, для вызова метода myFunction() из одного дочернего класса и вругом в таком виде не допустим?

package main{
	import flash.display.MovieClip;
 
	public class MainClass extends MovieClip {		
		private var theElseClass1:ElseClass1 = new ElseClass1();
		public var theElseClass2:ElseClass2 = new ElseClass2();
 
		public function MainClass() {
			addChild(theElseClass1);
			addChild(theElseClass2);
			theElseClass1.myConstructor();
		}		
	}
}

package main{
	import flash.display.MovieClip;
 
	public class ElseClass1 extends MovieClip {	
 
		public function ElseClass1() {				
		}	
		public function myConstructor() {
			(parent as MainClass).theElseClass2.myFunction();
		}
	}
}

package main{
	import flash.display.MovieClip;	
 
	public class ElseClass2 extends MovieClip {
 
		public function ElseClass2() {				
		}
		public function myFunction() {
			trace("trace it");
		}
	}
}

[etc]

xpymbl4, ну, в общем, большие дяди так не делают.

[IDimitry]

Если можно, то побуду в роли просящего, чтобы не подумали, что я спорю. Просто очень хочу разобраться для себя.

Есть такая иерархия: главный паблиш-класс, динамик-класс элемента на сцене, класс сокета и, к примеру, вспомагательный класс с константами и припертями (набор статических переменных для констант и сеттеров/геттеров для пропертей).
- сокет создается из главного класса;
- класс препертей и констант создается в конструкторе главного класса;
- мувик создается в произвольное время (т.е. можно положить на сцену, а можно динамически создать).

1. Если необходимо в зависимости от действий динамического мувика отослать данные через сокет, как с точки зрения правильной архитектуры это логичнее сделать? - Первое, что приходит в голову, - передать мувику ссылку на сокет. Второе - прописать сокет в проперти-объект, созданный в главном классе, и вызывать из дочернего родительский объект проперти, в котором есть свойство сокет. Я так понимаю, согласно подходам по принципу "черных ящиков", эти варианты неправильны? - Надо инициировать/делегировать события главному классу, который сам работает с сокетом?
2. В главном классе создаем экземпляр класса пропертей, в котором удобно держать "глобальные" переменные и константы. Понятно, что с созданием в другом классе нового экземпляра класса пропертей, данные в последнем будут не уникальны. Поэтому напрашиваются 3 решения: передача ссылки на созданный экземплят, создания синглтона или обращение к главному классу, в котором создан этот экземпляр. Опять же, согласно расхожему мнению, синглтон - это плохо, а два других способа противоречат "черному ящику". Но тут событие не пошлешь ... как правильно?

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

[GBee]

Синглтон - это не плохо, просто надо правильно использовать.
Обычно дети (не путать с наследниками) шлют события родителю, а родитель сам решает что и с кем делать.

в частности ElseClass1 должен был крикнуть папе MainClass "Пусть ElseClass2 помоет пол" и папа услышав, решит ага пусть. А в примере ElseClass1 говорит ElseClass2у - папа сказал тебе помыть пол :о)

[etc]

IDimitry,

1) Этим должен заниматься контроллер, получающий события от вьюверов. Типичный MVC.

2. Опять же, вы мыслите на уровне, что какой-то экземпляр должен сам доставать необходимые данные. Почему нельзя заранее дать необходимые данные экземпляру?

В общем и целом, познакомтесь с идеологией MVC и тогда проблемы с обращением к родителям отпадут сами с собой.