Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 16.03.2010, 09:10
etc вне форума Посмотреть профиль Найти все сообщения от etc
  № 11  
Ответить с цитированием
etc
Et cetera
 
Аватар для etc

Регистрация: Sep 2002
Сообщений: 30,784
Полезно отмечать методы как final, если нужно сохранить к ним доступ в наследниках, но при этом запретить переопределение, т. к. оно может повлиять на работоспособность.

Старый 16.03.2010, 11:12
switcher! вне форума Посмотреть профиль Отправить личное сообщение для switcher! Найти все сообщения от switcher!
  № 12  
Ответить с цитированием
switcher!

Регистрация: May 2009
Сообщений: 220
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Для базового класса он и останется this.hasUnit. А для потомка - super.hasUnit. Не понял суть проблемы.

То есть вызовы методов вкомпилятся инлайново?
хорошо, дополним пример. Имеем в базовом классе:
Код AS3:
public function hasUnit(unit:IUnit):Boolean {
	//search unit
}
 
private function _doSomeThing():void {
	...
	if (this.hasUnit(tank)) ...;
	...
}
Имеем в классе-наследнике:
Код AS3:
override public function hasUnit(unit:IUnit):Boolean {
	// no call super.hasUnit()
	var myVar:Boolean;
	...
	return myVar;
}
Что теперь произойдет при вызове _doSomeThing, определенного в супер-классе? Понятия не имею. Это уже неконтролируемая цепочка действий.

Конечно, когда программист один, такое можно и предусмотреть. А когда несколько? Вот захотелось напарнику переопределить hasUnit для целей наследника. Зачем ему лезть в твой супер-класс и смотреть как бы не поломать логику в наследнике? Нужно создать такие условия, которые бы помешали ему несознательно нарушить логику супер-класса.

Старый 16.03.2010, 11:55
r_r_f_r вне форума Посмотреть профиль Отправить личное сообщение для r_r_f_r Найти все сообщения от r_r_f_r
  № 13  
Ответить с цитированием
r_r_f_r

Регистрация: Sep 2008
Адрес: Москва
Сообщений: 224
Эдобы предлагают использовать для вызова переопределённого метода дальнего предка, например:
Код AS3:
public class A
{
      public function a():void
      {
      }
}
 
public class AA extends A
{
       override public function a():void
       {
       }
 
       final public function $a():void
       {
                super.a(); 
       }
}

И так далее в каждом наследнике добавлением $.

Старый 17.03.2010, 18:36
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 14  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Что теперь произойдет при вызове _doSomeThing, определенного в супер-классе? Понятия не имею. Это уже неконтролируемая цепочка действий.
Что то бред какой-то. Выполнится код суперкласса, код отработает и что нибудь сделает, как будто бы наследника никогда и не было, хотя бы потому что к _doSomeThing у наследника доступа то и нет - какая ещё неконтролируемая цепочка?

Цитата:
Конечно, когда программист один, такое можно и предусмотреть. А когда несколько? Вот захотелось напарнику переопределить hasUnit для целей наследника.
Ну как бы полиморфизм никто не отменял - и при обращении в нормальных неймспейсах через super к методам базового класса ничего не произойдёт - отработает, как будто бы наследника не было.
Цитата:
Нужно создать такие условия, которые бы помешали ему несознательно нарушить логику супер-класса.
Ну, э... заэкстендся от ЭвентДиспатчера и попробуй сознательно нарушить его логику. Инкапсуляция тебе не позволит - а к нужным мне методом я всё равно достучусь через super.

r_r_f_r, понятно, спасибо. Это уже реально похоже на практическую ценность. А $ - это правильно так писать, или это ради примера лишь? Я про Code Conversion, или как он там.

Старый 17.03.2010, 20:23
Rzer вне форума Посмотреть профиль Отправить личное сообщение для Rzer Посетить домашнюю страницу Rzer Найти все сообщения от Rzer
  № 15  
Ответить с цитированием
Rzer
 
Аватар для Rzer

блогер
Регистрация: Feb 2007
Адрес: Spb
Сообщений: 612
Записей в блоге: 8
Отправить сообщение для Rzer с помощью ICQ
Цитата:
Сообщение от dimarik Посмотреть сообщение
Второе не нашло пока применение в моей практике.
Переписываем setter url в наследнике URLRequest (чтобы ничего не менялось) и подсовываем api_wrapper'у вкотакте url с javascript.

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


Последний раз редактировалось Rzer; 18.03.2010 в 00:54.
Старый 18.03.2010, 00:28
switcher! вне форума Посмотреть профиль Отправить личное сообщение для switcher! Найти все сообщения от switcher!
  № 16  
Ответить с цитированием
switcher!

Регистрация: May 2009
Сообщений: 220
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Выполнится код суперкласса, код отработает и что нибудь сделает
верно, что-нибудь. Например, порушит всю программу Почему? Потому что метод _doSomeThing вызовет не метод hasUnit, определенный в базовом классе, а переопределенный метод hasUnit в наследнике. А что вернет переопределенный hasUnit известно только тому, кто будет этот метод переопределять.

Для _doSomeThing эта ситуация выглядит так:
Код AS3:
private function _doSomeThing():void {
	...
	//if (this.hasUnit(tank)) ...;
	if (Math.random() - 0.5 > 0) ...;
	...
}
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
хотя бы потому что к _doSomeThing у наследника доступа то и нет - какая ещё неконтролируемая цепочка?
у наследника доступа нет, но есть у его суперкласса. В чем проблема?
Или вы считаете, что при создании объекта TankGroup метод _doSomeThing не выполниться (код ниже)?

Код AS3:
public class Group
{
      public function Group(units:Array):void {
            super();
            ....
            this._doSomeThing();
      }
      ...
}
 
public class TankGroup extends Group
{
      public function Group(tanks:Array):void {
            super(tanks);
            ....
      }
 
       override public function hasUnit(unit:IUnit):Boolean {
              ...
       }
 
}
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Ну как бы полиморфизм никто не отменял - и при обращении в нормальных неймспейсах через super к методам базового класса ничего не произойдёт - отработает, как будто бы наследника не было.
Вы меня не слушаете. В примерах рушится логика НЕ наследника, а супер-класса. А этого нужно избегать, особено если вы программируете черные ящики.

Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Ну, э... заэкстендся от ЭвентДиспатчера и попробуй сознательно нарушить его логику. Инкапсуляция тебе не позволит - а к нужным мне методом я всё равно достучусь через super.
Мне одному видится, что этой фразой Psycho Tiger правильно ответил на все остальные вопросы?


Последний раз редактировалось switcher!; 18.03.2010 в 00:30.
Старый 18.03.2010, 16:05
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 17  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
switcher, я правда не понимаю вообще ничего из того, что вы мне пытаетесь донести.
Провёл тест:
Код AS3:
package  
{
	import flash.display.Sprite;
 
	/**
	 * ...
	 * @author Artem Shlagin
	 */
	public class JustMain extends Sprite
	{
 
		public function JustMain() 
		{
			super();
			var myClass:SecondClass = new SecondClass();
			myClass.runBaseClassTest();
		}
 
	}
 
}
Код AS3:
package  
{
	/**
	 * ...
	 * @author Artem Shlagin
	 */
	public class BaseClass
	{
 
		public function BaseClass() 
		{
			super();
			trace("I`m base class constructor");
		}
 
		public function someMethod():void {
			trace("BASE CLASS: Some method");
		}
 
		protected function runTest():void {
			trace("BASE CLASS: Run test");
		}
 
	}
 
}
Код AS3:
package  
{
	/**
	 * ...
	 * @author Artem Shlagin
	 */
	public class SecondClass extends BaseClass
	{
 
		public function SecondClass() 
		{
			trace("I`m daughter");
		}
 
		override public function someMethod():void 
		{
			trace("Some method -> DAUGHTER!!!");
		}
 
		public function runBaseClassTest():void {
			super.runTest();
		}
 
	}
 
}
Если я правильно понял вашу идею, то вызвав runTest у нашего суперкласса должен был бы вызваться
Код AS3:
override public function someMethod():void 
{
	trace("Some method -> DAUGHTER!!!");
}
и порушить логику работы.
Output:
Цитата:
I`m base class constructor
I`m daughter
BASE CLASS: Run test
Значит, я прав. Или я опять вас не так понял?

Цитата:
верно, что-нибудь
Это в смысле "сделает то, что должна была бы сделать".

Цитата:
Вы меня не слушаете. В примерах рушится логика НЕ наследника, а супер-класса. А этого нужно избегать, особено если вы программируете черные ящики.
Можно рабочий пример? Тест выше не порушил, не знаю как вам это удастся =/
Цитата:
Мне одному видится, что этой фразой Psycho Tiger правильно ответил на все остальные вопросы?
Тоже совсем не понял.

UPD: Блиииииин... А вызов то метода забыл, и правда, вызовется ребёнок. Да, switcher, вы правы. Вопросы отпали. Хотя я так и не понял, что вы хотели сказать своей последней фразой


Последний раз редактировалось Psycho Tiger; 18.03.2010 в 16:08.
Старый 18.03.2010, 22:38
switcher! вне форума Посмотреть профиль Отправить личное сообщение для switcher! Найти все сообщения от switcher!
  № 18  
Ответить с цитированием
switcher!

Регистрация: May 2009
Сообщений: 220
Да, собственно, подчеркнул правильность мысли по поводу EventDispatcher, которую в частности отражает введение в код приватного метода _hasUnit (в первом моем посте топика)

Старый 18.03.2010, 23:10
dimarik вне форума Посмотреть профиль Отправить личное сообщение для dimarik Найти все сообщения от dimarik
  № 19  
Ответить с цитированием
dimarik
.
 
Аватар для dimarik

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Цитата:
Сообщение от switcher! Посмотреть сообщение
Да, собственно, подчеркнул правильность мысли по поводу EventDispatcher, которую в частности отражает введение в код приватного метода _hasUnit (в первом моем посте топика)
Собственно, то, что Вы предложили в качестве "bad practice" есть GOF-шаблон Factory method. Он предполагает абстрактный класс и обязательное переопределение методов в потомках. Как недопустить этого- о, да, final, либо private/anonymouse namespace.

Добавлено через 1 минуту
Цитата:
Сообщение от Rzer Посмотреть сообщение
Переписываем setter url в наследнике URLRequest (чтобы ничего не менялось) и подсовываем api_wrapper'у вкотакте url с javascript.

В качестве аргумента новый класс прокатил бы, так как он наследник от URLRequest, но final и тут не поспоришь.
Вот это более понятно.
__________________
Воспитан в TimeZero. Работаю в Mail.ru.

Старый 18.03.2010, 23:35
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 20  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Всё равно не понял

Создать новую тему Ответ Часовой пояс GMT +4, время: 14:39.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 14:39.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.