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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 13.12.2017, 14:47
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию Интерфейс и его имплементация

Вопрос по книге Сандерса о паттернах проектирования в AS3 (Купил вчера в PDF в прекрасном качестве, весь код можно копипастить, если кому надо книжку, с радостью поделюсь). Авторы пишут о предпочтении "программирования от интерфейса (супертипа), а не его имплементации". В качестве примера приводится то, что в моей программе выглядело бы вот так:

Код AS3:
private var hero:Character = new Hero();
разумеется, Hero - наследник Character. Я правильно понимаю, что при таком объявлении во-первых, не будет ошибки компиляции, во-вторых, везде, где параметр типизируется как Character, мой передаваемый туда hero также пройдёт без ошибок, и в-третьих, если где-то будет обращение к свойству другого наследника Character (например Enemy), я сразу получу ошибку в рантайме?

И что вообще уважаемые знатоки думают о таком подходе?

Старый 13.12.2017, 14:58
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 2  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
ты сразу ограничиваешь функционал своего героя суперклассом Character, теряя всю специфику Hero

Старый 13.12.2017, 15:03
illuzor вне форума Посмотреть профиль Отправить личное сообщение для illuzor Найти все сообщения от illuzor
  № 3  
Ответить с цитированием
illuzor
 
Аватар для illuzor

Регистрация: Dec 2010
Адрес: Ярославль
Сообщений: 1,255
Цитата:
И что вообще уважаемые знатоки думают о таком подходе?
Такой "подход" называется полиморфизмом - это один из принципов ООП. Изучите сначала его, чтобы не задавать подобные странные вопросы.

Старый 13.12.2017, 16:10
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 4  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от illuzor Посмотреть сообщение
Такой "подход" называется полиморфизмом - это один из принципов ООП. Изучите сначала его, чтобы не задавать подобные странные вопросы.
Вообще-то я привёл ход рассуждения. Тот полиморфизм, который я знаю (хотя безусловно не претендую на экспертность ни в какой степени, поэтому и спрашиваю), вполне будет "работать" и в такой форме:

Код AS3:
public var hero: Hero = new Hero();
при условии, что Hero - наследник Character. Более того, если какой-то метод в Character будет записан как "абстрактный" и переопределён в классе-наследнике Hero, то в соответствии с принципом полиморфизма он будет корректно вызван для экземпляра типа Hero, несмотря на то, что объявлен он не с использованием имени суперкласса. Собственно об этом и вопрос.

Старый 13.12.2017, 19:54
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 5  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Цитата:
если где-то будет обращение к свойству другого наследника Character (например Enemy), я сразу получу ошибку в рантайме?
Ты получишь ошибку компиляции при обращении к свойству Enemy или Hero, без разницы.

Ты объявил переменную как Character. Абсолютно неважно, что ты туда запихаешь в рантайме. Компилятор видит, что ты пытаешься вызвать несуществующий метод именно у Character. Это тип переменной, и он не зависит от того, какой конкретно объект туда записан.
__________________
Reality.getBounds(this);

Старый 13.12.2017, 21:33
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 6  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Это тип переменной, и он не зависит от того, какой конкретно объект туда записан.
На фига тогда так писать? Или предполагается, что суперкласс полностью абстрактный и не содержит ВООБЩЕ никакой реализации, оставляя всё своим наследникам?
__________________
Не сломано - не чини!

Старый 13.12.2017, 21:43
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 7  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
часто так пишут в сигнатурах методов, а не при объявлении переменных.
Код AS3:
public function doSomething(character:Character):void

Старый 13.12.2017, 21:44
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 8  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Я не понимаю этого вопроса.
Ну вот у тебя допустим объявлена переменная типа Спрайт.
Ты можешь туда любую кнопку запихать.
Но если ты в коде обратишься к этой переменной не как к Спрайту, а как к кнопке, то получишь ошибку компиляции? Конечно получишь, потому что у Спрайта нет таких свойств которые ты добавил в кнопку-наследника. Для компилятора это Спрайт! Потому что переменная имеет тип Спрайт. И компилятору не надо дожидаться рантайма чтобы указать тебе на ошибку: ты вызываешь свойства и методы, которых нет у данного типа. Если хочешь обращаться к свойствам и методам кнопки, укажи что это кнопка и проблем не будет. Что тут нелогичного?
__________________
Reality.getBounds(this);

Старый 13.12.2017, 22:02
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 9  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Как будто это я придумал
Вот смотрите из книги по шаблонам проектирования, буквально первая глава:
Код AS3:
// Абстрактный класс
public class Polymorphism
{
public function myMusic():void { // Резервные детали для подклассов }
}   public class Rock extends Polymorphism {
override public function myMusic():void { trace(“Play Jimmie”); }
}   import flash.display.Sprite; public class PlayMusic extends Sprite
{ var rock:Polymorphism; var classic:Polymorphism; var country:Polymorphism; var jazz:Polymorphism; public function PlayMusic():void { rock=new Rock(); rock.myMusic();
Вот видите, как в самом конце всё собирается вместе?
__________________
Не сломано - не чини!

Старый 13.12.2017, 22:44
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 10  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
И? Класс Rock же не создал новый метод, которого нет в Polymorphism. Он переопределил суперметод. В этом и заключается полиморфизм. А вопрос то в чем?)

Переменная rock имеет тип Polymorphism.
У типа Polymorphism есть метод myMusic().
У переменной rock вызывается метод myMusic(), который есть у ее типа.
Где тут компилятору кричать "Караул!"?
__________________
Reality.getBounds(this);

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

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

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


 


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


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