организация кода в игре

[caseyryan]

Неужели для добавления в DisplayList нужно приводить тип as DisplayObject? Я прост не пользовался интерфейсами никогда)

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

Да не нужны в ас3 интерфейсы , не партесь, это все для максимальной чистоты кода, не больше, а вот проблем типа addChild - навалом.

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

[MikroAcse]

Да не нужны в ас3 интерфейсы

Ничего себе заявления. Давай ты останешься с ними сам.
А вот есть случаи, когда без них не обойтись.

[in4core]

А вот есть случаи, когда без них не обойтись.

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

[ChuwY]

Есть случаи, когда с ними проще и удобнее.
Пара случаев, которые вспоминаются тут же (нет времени вспоминать больше):
1. Интерфейс IClearable для объектов, которые мы берем и возвращаем из пула, да и не только.
Сами объекты могут быть, как въюшками, так и моделями и общие предки им ни к чему, а интерфейс помогает.
2. Библиотеки для поиска пути и прочего подобного.
Некоторые методы могут принимать контейнер, от которого требуются определенные методы доступа.
Иногда контейнер уже есть и проще реализовать интерфейс, дописав необходимые методы.

[in4core]

Есть случаи, когда с ними проще и удобнее.

Удобнее и проще - это тоже сомнительное утверждение. Проще когда КОД простой, а не когда накручено всякой чуши , интерфейсов и Н паттернов. Лично я к этому уже пришел, вы возможно еще нет, поэтому утверждаете обратное.
Как говорил один умный человек : (не дословно) Даже самый простой проект в котором начинают использовать MVC и прочее - скорее всего перерастет из маленькой проблемы в постоянную головную боль.
*
Это я не к тому, что давай те писать все в Меин, нет, организация кода по правилам ООП должна быть обязательно, но наворачивать - смысла нет, только себе хуже.

Иногда контейнер уже есть и проще реализовать интерфейс, дописав необходимые методы.

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

[ChuwY]

Я 95% времени работаю в команде и рассуждаю именно с такой точки зрения.

Кто мешает просто дописать методы без интерфейса ?

Проблема в том, что контейнер твой, а библиотека сторонняя и универсальная.
Она понятия не имеет о твоем классе.

[caseyryan]

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

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

Сань, от части ты прав, но ты же сам понимаешь, что реально бывают случаи, когда с интерфейсами намного проще и понятнее.
Бывает так, что в конструктор передаются разные объекты, которые могут расширять совсем разные базовые классы, допустим один расширяет Sound, а другой Sprite. Расширить один они не могут (ну, если не Object).
Но у них есть общий метод, например update();, который должен дальше вызываться. И метод должен гарантировано быть. Вот тут реально использовать интерфейс лучше и удобнее, чем Object в конструкторе

[in4core]

Сань, от части ты прав, но ты же сам понимаешь, что реально бывают случаи, когда с интерфейсами намного проще и понятнее.
Бывает так, что в конструктор передаются разные объекты, которые могут расширять совсем разные базовые классы, допустим один расширяет Sound, а другой Sprite. Расширить один они не могут (ну, если не Object).
Но у них есть общий метод, например update();, который должен дальше вызываться. И метод должен гарантировано быть. Вот тут реально использовать интерфейс лучше и удобнее, чем Object в конструкторе

Кость, да я и не спорю. Я просто говорю о том, что не стоит зарываться в это с головой и рассуждать так, что ИФейс это жизнь. Твой пример самый частый, когда нужны Ифейсы, но и самый редкий в жизни. То есть случаи есть - где это удобнее и красивее, но их настолько мало и они всплывают редко, что в общей рутине - просто исчезают из вида. Сложно сказать опять же, кому как, раньше я тоже везде их сувал по делу и не по делу, а потом почувствовал рельаное неудобство и перестал ими пользоваться вообще. В крайнем случае я вместо Object - сделаю * no type и успокоюсь Вообщем каждый для себя решает сам, тут не поспоришь, сколько людей, столько и мнений

[ZackMercury]

А это уже холивар
В общем, пусть ТС сам попробует использовать интерфейсы и если ему не понравится - пусть также как и вы от них откажется.