Про интерфейсы и их реализации
 

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

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

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

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

Спасибо.

Можешь. А можешь и не записывать, а сделать вот так, к примеру
И потом применить только IMovable. Это гарантирует что у твоего класса будут и методы moveTo() и dispose()
Наследуй так же как обычно. Применение классом каких-либо интерфейсов не противоречит обычному наследованию им другого класса.

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

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

caseyryan, спасибо. Исчерпывающе.

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

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

Это и есть полиморфизм, один из 3(4) основных принципов ООП

Добавлено через 4 минуты
И кроме того, интерфейсы, например, здесь:
Позволяют тебе как абстрагироваться от ненужных полей объекта, так и не париться насчет реализации методов интерфейса, требуя только, чтобы они были

да-да, интерфейсы это именно полиморфизм, для этого и созданы - чтобы можно было воткнуть в интерфейс любой объект, его имплементирующий. При этом использующий этот интерфейс класс ни сном ни духом о том, какой именно он объект использует. Именно это позволяет реализовать принцип модульности: когда у тебя есть некий фрэймворк (большой кусок программы), к которому через интерфейсы подключается другой большой кусок программы. И эти куски друг о друге ничегошеньки не знают, а лишь используют интерфейсы друг друга. Таким образом, можно их тасовать, таскать в разные программы по возможности без потерь.

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

Спасибо.

1. Нет
2. Положительно, если нет других идей. С другой стороны смысл такого интерфейса, если от него по сути ничего не ждешь?

1. Жаль. Это в AS3 такое упущение или в целом в ООП подобное не принято?
2. Мне представляется смысл в том, что используешь "сильную" типизацию, можешь проверять на принадлежность типу, оставляешь пространство для настройки специфики добавлением методов в будущем.

1. В клуб проходят только негры до 25 лет. Душой я черный и мой психологический возраст 18, но я вам этого показать не могу, надо вскрывать, так сказать ломать капсулу. Вы меня пропустите?
2. Ну если на будущее, то может быть имеет смысл. Только как бы не получилось, что маркером вдруг отметились все сущности.

1. Понял-отстал.
2. Изначально есть оружие колющее и режущее. Пока публичные свойства и методы у них одинаковые, но кое-что уже отличается, например, это влияет на выборе варианта атаки. Изначально думал сделать наследников, но появились такие экземпляры, которые относятся сразу к двум типам. Пришлось сделать вектор строковых ID, со всеми его неудобствами. Сейчас, когда я чудесным образом открыл для себя всю прелесть интерфейсов, пришёл к заключению, что правильнее и компактнее будет ввести соответствующие интерфейсы, присваивать их и проверять экземпляры на принадлежность нужному.

Интерфейсы, всегда и везде, объявляют только public методы и функции. Поэтому в интерфейсах и не указывается модификатор доступа, ибо он и так понятен
Никогда не использую. По-моему, если приходится юзать такой подход, то что-то не так с архитектурой приложения. По сути, это можно использовать только лишь для проверки типа. Чтобы сделать с таким объектом что-то другое, тебе все равно придется приводить его к какому-то другому типу

На практике такое встречал редко. В целом, это избыточно.

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

Маркерные интерфейсы используются, когда надо выразить не ЧТО ДЕЛАЕТ объект, а ЧТО МОЖНО СДЕЛАТЬ с ним. Что значит "сделать с ним"? Ну, обычно это значит "передать аргументом в какую-то функцию", ибо "делают" у нас функции. Например, можно пометить какие-то предметы разных классов как ДобавлябельныеВИнвентарь. Но, как правильно заметил Кейси, это лишь отодвигает проблему вглубь — в инвентаре все-равно придется разбираться что это за фрукт. Тем не менее, положа руку на сердце, добавляемые в инвентарь предметы могут на самом деле не иметь общих методов, так как используются совершенно по-разному, и даже индивидуальную иконку иметь не обязаны, а такие поля как name или ID — общие для ВСЕХ объектов, а не только Добавлябельных. Так что в каких-то ситуациях это может быть инструментом, упрощающим архитектуру — если какой-то метод реально готов принимать для обработки объекты разных типов.

Не легче ли создать enum, хранящий все ID? В AS3 нет перечисляемого типа, но его можно легко симулировать

Добавлено через 3 минуты
Добавлено через 6 минут
Любопытный клуб :)