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

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

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

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

Друзья, я добрался-таки до интерфейсов (правы были те, кто говорил, что сам поймёшь, когда они тебе понадобятся, а до поры не трогай). Освежил инфу из Мука, GoF и сотоварищи. И один принцип меня запутал. "Наследуйте интерфейсы, а не их реализации", - отлито в граните. А вот как наследование интерфейсов сочетается (и должно ли сочетаться?) с наследованием классов - у меня пока полная каша.

Практическая задача такая. В Модели в менеджере экипировки есть слот используемого предмета (условно то, что взято в руки). Сюда могут попадать экземпляры разных классов. Создаю интерфейс IEquippable, пока всё понятно. При этом у меня есть система статусов, в т.ч. и для предметов (типа "зачарован", или "смазан ядом"). Экипируемый предмет обязан это дело поддерживать. Значит, нужен интерфейс IStatusManager.

Вопросы:
1. Если 2 интерфейса имплементируются одновременно, то я могу записать их через запятую:
Код AS3:
public class SomeClass implements IEquippable, IStatusManager
а могу унаследовать один от другого. Собственно, вопрос, на фига наследовать, если всегда можно перечислять? Вроде и гибкость бОльшая.

2. Предположим, что интерфейсы унаследованы, и один расширяет другой. Как в таком случае рекомендуется организовывать классы, использующие их? Вроде как расширять теми же методами, что описаны в интерфейсах - масло масленое. Как тогда: делать их полностью независимыми или наследовать по каким-то другим критериям, не описанным в интерфейсе? Пока такие конструкции (отдельная линия наследования "по классу" и отдельная "по интерфейсу") в голове просто не умещаются

Спасибо.
__________________
Не сломано - не чини!

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
1. Если 2 интерфейса имплементируются одновременно, то я могу записать их через запятую:
Можешь. А можешь и не записывать, а сделать вот так, к примеру
Код AS3:
public interface IDisposable {
     function dispose():void;
}
public interface IMovable extends IDisposable {
     function moveTo(x:Number, y:Number):void; // у этого интерфейса будет и описание метода dispose(), но самому IMovable он как бы не нужен
}
И потом применить только IMovable. Это гарантирует что у твоего класса будут и методы moveTo() и dispose()
Цитата:
Как тогда: делать их полностью независимыми или наследовать по каким-то другим критериям, не описанным в интерфейсе?
Наследуй так же как обычно. Применение классом каких-либо интерфейсов не противоречит обычному наследованию им другого класса.
Код AS3:
public class SomeClass extends Sound implements IDisposable {
   public function SomeClass () {}
   public function dispose():void {} // обязательно применяет метод интерфейса. Без этого даже не скомпилится
}
public class SomeMovableClass extends Sprite implements IMovable {
    public function SomeMovableClass () {}
    public function moveTo(x:Number, y:Number):void { // обязательно применяешь
        // какая-то логика
    }
    public function dispose():void { // так же обязательно. потому что есть в IDisposable
 
    }
}
 
....
var movable:SomeMovableClass = new SomeMovableClass();
trace(movable is IDisposable); // true
trace(movable is IMovable); // true
var someClass:SomeClass = new SomeClass();
trace(someClass is IDisposable); // true
trace(someClass is IMovable); // false
__________________
Ко мне можно и нужно обращаться на ты)

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Интерфейсы очень удобны на стыках сред, библиотек, для уменьшения связанности. Например, физ. движок может использовать их для описания некоторых своих сущностей для "внешнего" кода. Или графический фреймворк, предоставляя таким образом большую гибкость. В рамках логики самого проекта, они, ну, не так часто нужны. Можно, конечно, по всякому извращаться, например, повторить всё апи модели (МВЦ!!!) в отдельной ветке интерфейсов, засунуть их везде где только можно. Такое себе занятие))

Интерфейс - просто один из инструментов, который может быть полезнее/удобнее других в некоторых ситуациях. Ближайший аналог - Абстрактные/базовые классы.
__________________
Дети не должны знать о своих родителях

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
caseyryan, спасибо. Исчерпывающе.

Цитата:
В рамках логики самого проекта, они, ну, не так часто нужны. Можно, конечно, по всякому извращаться, например, повторить всё апи модели (МВЦ!!!) в отдельной ветке интерфейсов, засунуть их везде где только можно. Такое себе занятие))
Tails, мне пока потребовалось в частности для защиты от дурака. Если какие-то классы обязаны уметь делать что-то определённое (в моём случае инициализироваться, а потом закрываться от дальнейших обновлений данных), то им удобно раздать соответствующий интерфейс и не париться.

Или, например, когда какой-то класс выбивается из общей логики, но обязан встраиваться в обычные методы обработки. Как я понимаю, в этом и есть сила и преимущество интерфейсов. Используя их, необязательно тянуть все "потроха" предков, достаточно просто прописать методы, а внутри уже творить, что хочешь.
__________________
Не сломано - не чини!

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

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Цитата:
Сообщение от Appleman Посмотреть сообщение
Или, например, когда какой-то класс выбивается из общей логики, но обязан встраиваться в обычные методы обработки. Как я понимаю, в этом и есть сила и преимущество интерфейсов
Это и есть полиморфизм, один из 3(4) основных принципов ООП

Добавлено через 4 минуты
И кроме того, интерфейсы, например, здесь:
Код AS3:
var block:IMovable = getBlockBehind()
Позволяют тебе как абстрагироваться от ненужных полей объекта, так и не париться насчет реализации методов интерфейса, требуя только, чтобы они были
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

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

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
да-да, интерфейсы это именно полиморфизм, для этого и созданы - чтобы можно было воткнуть в интерфейс любой объект, его имплементирующий. При этом использующий этот интерфейс класс ни сном ни духом о том, какой именно он объект использует. Именно это позволяет реализовать принцип модульности: когда у тебя есть некий фрэймворк (большой кусок программы), к которому через интерфейсы подключается другой большой кусок программы. И эти куски друг о друге ничегошеньки не знают, а лишь используют интерфейсы друг друга. Таким образом, можно их тасовать, таскать в разные программы по возможности без потерь.
__________________
while(live()) { hope(); }

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

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Ребята, ещё пара вопросов по интерфейсам:
1. Возможно ли создать интерфейс, обязывающий классы реализовывать определённые ПРИВАТНЫЕ методы?
2. Что думаете на счёт использования интерфейсов-"пустышек" (т.е. без прописанных методов) для целей маркировки объектов, тем самым реализуя множественное типирование (как альтернатива излюбленной тактике зафигачить строковые ID)?

Спасибо.
__________________
Не сломано - не чини!

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

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Сообщение от Appleman Посмотреть сообщение
Ребята, ещё пара вопросов по интерфейсам:
1. Возможно ли создать интерфейс, обязывающий классы реализовывать определённые ПРИВАТНЫЕ методы?


Спасибо.
Интерфейсы, всегда и везде, объявляют только public методы и функции. Поэтому в интерфейсах и не указывается модификатор доступа, ибо он и так понятен
Цитата:
2. Что думаете на счёт использования интерфейсов-"пустышек" (т.е. без прописанных методов) для целей маркировки объектов, тем самым реализуя множественное типирование (как альтернатива излюбленной тактике зафигачить строковые ID)?
Никогда не использую. По-моему, если приходится юзать такой подход, то что-то не так с архитектурой приложения. По сути, это можно использовать только лишь для проверки типа. Чтобы сделать с таким объектом что-то другое, тебе все равно придется приводить его к какому-то другому типу
__________________
Ко мне можно и нужно обращаться на ты)

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

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Цитата:
Сообщение от Appleman Посмотреть сообщение
Ребята, ещё пара вопросов по интерфейсам:
2. Что думаете на счёт использования интерфейсов-"пустышек" (т.е. без прописанных методов) для целей маркировки объектов, тем самым реализуя множественное типирование (как альтернатива излюбленной тактике зафигачить строковые ID)?
Спасибо.
На практике такое встречал редко. В целом, это избыточно.

Подумай о том, чтобы вынести все данные игровых сущностей в отдельные классы/таблицы/списки, а не хранить их в виде типов, иерархий наследования, наличии строковых свойств и т.д.
__________________
Дети не должны знать о своих родителях

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

Регистрация: Jun 2014
Адрес: Санкт-Петербург
Сообщений: 185
Цитата:
Сообщение от Appleman Посмотреть сообщение
2. Что думаете на счёт использования интерфейсов-"пустышек" (т.е. без прописанных методов) для целей маркировки объектов, тем самым реализуя множественное типирование (как альтернатива излюбленной тактике зафигачить строковые ID)?
Не легче ли создать enum, хранящий все ID? В AS3 нет перечисляемого типа, но его можно легко симулировать

Добавлено через 3 минуты
Цитата:
Сообщение от Appleman Посмотреть сообщение
2. Изначально есть оружие колющее и режущее. Пока публичные свойства и методы у них одинаковые, но кое-что уже отличается, например, это влияет на выборе варианта атаки. Изначально думал сделать наследников, но появились такие экземпляры, которые относятся сразу к двум типам. Пришлось сделать вектор строковых ID, со всеми его неудобствами. Сейчас, когда я чудесным образом открыл для себя всю прелесть интерфейсов, пришёл к заключению, что правильнее и компактнее будет ввести соответствующие интерфейсы, присваивать их и проверять экземпляры на принадлежность нужному.
Код AS3:
public var type:WeaponType = WeaponType.STITCHING
Добавлено через 6 минут
Цитата:
Сообщение от GBee Посмотреть сообщение
1. В клуб проходят только негры до 25 лет
Любопытный клуб
__________________
В прошлом - AS3 программист, в данный момент пишу на Haxe

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

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

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


 


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


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