|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
блогер
Регистрация: Oct 2005
Адрес: Днепродзержинск - город Брежнева и других логопедов
Сообщений: 1,421
Записей в блоге: 4
|
Возможно. Но в AS3 можно унаследоваться только от одного класса. И если реально методы класса, который будете расширять вызываться не будут (будут вызываться только методы наследников, у всех разные, все наследники делают override), то надо таки сделать интерфейс, ибо незачем тягать сигнатуры лишние.
__________________
Бобры отвечают на вопросы не потому, что знают на них ответы; они отвечают потому, что их спрашивают. |
|
|||||
Негуру
администратор
Регистрация: Jan 2000
Адрес: Кёнигсберг in Moscow
Сообщений: 21,879
Записей в блоге: 7
|
Цитата:
1. Не всегда. Попробуйте сделать такой общий класс для Sprite и Bitmap. 2. Зачем, когда для этого есть интерфейс? |
|
|||||
[+1 23.05.11]
Регистрация: Dec 2001
Сообщений: 4,159
|
Цитата:
Правильный пример: у нас есть старинный чугунный утюг, электроутюг и сковорода. У нас есть интерфейс ФиговинаДляГлажки. Все три реализуют этот интерфейс, т.е. гладить можно и электроутюгом, и чугунным утюгом, и разогретой сковородой. Делают они это по-разному, но все выполняют один и тот же контракт -- глажку.
__________________
GIT d++ s++:++ a C++$ UB++ P++ L+ E+ W+++ N++ w++ O+ M V- t-- 5-- X+ R+++ tv- b+++ D++ |
|
|||||
Banned
[+1 05.11.11]
[+1 09.08.11] Регистрация: Jan 2010
Адрес: РФ. Кемеровская область
Сообщений: 3,243
|
Цитата:
Так же интерфейс может вообще не содержать никаких методов. Интерфейс задает классу еще один тип данных. Сколько интерфейсов применяет класс, столько у него и типов данных. Вообще, автору темы стоит забить пока на интерфейсы и читать книжку дальше. Со временем будет намног понятнее. |
|
|||||
[+1 23.05.11]
Регистрация: Dec 2001
Сообщений: 4,159
|
В скомпилившемся коде -- гарантирует.
__________________
GIT d++ s++:++ a C++$ UB++ P++ L+ E+ W+++ N++ w++ O+ M V- t-- 5-- X+ R+++ tv- b+++ D++ |
|
|||||
я вот тоже не дорос еще до интерфейсов и никак не могу понять зачем они мне нужны. с моей точки зрения, это всего лишь напоминалка не забыть реализовать какой-то метод.
если я буду парочку своих классов имплементить, то мне придется в одном и том же методе у двух классов реализовывать какой-то набор команд. но у меня не возникало еще ситуаций, когда эти команды отличаются полностью. я предпочитаю общую часть этих команд реализовать в надклассе, а в наследованных классах вызвать метод надкласса через супер и реализовать лишь различающиеся команды. если мне потребуется еще один класс унаследовать, то в нем возможно вообще не будет уникальных команд для этого метода. поэтому я этот метод не буду вообще оверрайдить. в случае же с интерфейсом, мне пришлось бы опять копипастить метод. -- кто то сможет на моем примере показать преимущество интерфейсов? |
|
|||||
Banned
[+1 05.11.11]
[+1 09.08.11] Регистрация: Jan 2010
Адрес: РФ. Кемеровская область
Сообщений: 3,243
|
Это скорее не для того, чтобы гарантировать наличие методов, а для того, чтобы абсолютно разные классы принадлежали к одному типу данных.
Допустим диспатчат 2 разных класса одно событие и при этом оба класса применяют общий интерфейс (допустим ISomeInterface), но есть еще и другие классы, которые тоже диспатчат это событие. Нам же нужно делать что-то только с теми классами, которые применяют этот интерфейс. Для большей наглядности, допустим есть игра, в которой есть различные виды техники, которую нужно уничтожать. Все виды транспорта будут, естественно, принадлежать к разным классам (Car, Tank, Aaa и т.д.), но есть у них и одно общее, они все должны взрываться. Для этого создаем интерфейс, например IBlowable, с методом blow(); И имплементим его во всех классах техники. Теперь, при попадании бомбы в транспортное средство, мы можем проверить в обработчике события так: В этом случае нам не нужно будет проверять принадлежит ли цель к каждому конкретному виду техники, например так: Кто-то возможно скажет: "но ведь можно же, например, првоерить e.target is DisplayObject" И результат будет true. Но DisplayObject не имеет метода blow(); Вот, как-то так. Надеюсь не слишком стремное пояснение Последний раз редактировалось goodguy; 06.06.2011 в 21:34. |
|
|||||
[+4 06.05.14]
|
Да блин опять холивар развели )) в первых постах все пояснили что и зачем По факту, можно и штаны через голову надеть. Просто если хотите видеть красивый структурированный код = юзаем интерфейсы , там где это будет логично, а там где суперкласс - там суперклассы. Недавно была тема, я там пояснил = когда интерфейсы , а когда суперклассы.
В двух словах : superClass используем для объектов одного типа и имеющих одинаковые методы, лишь мельком различающиеся ( тут оверрайдим) , интерфейс когда объекты РАЗНЫХ типов ( ваза, чашка, стакан, витрина ) но все они имеют один и тот же метод CRASH!
__________________
Марк Tween |
|
|||||
Modus ponens
|
По поводу аналогии с розеткой: В глобальном плане она более правильная, чем аналогия с разными вещами для глажки, т.как интерфейс потому так и называется, что описывает способ общения с внешним миром (между поверхносями или между рельефами, ну как-то так), и не описывает, что он должен делать или для чего предназначен. CLI (Command Line Interface) не имеет конкретного назначения, вернее его назначение не более конкретно, чем назначение более широкого понятия, которое включает в себя CLI (общение с пользователем посредством командой строки)... Более того, это вполне себе правильно (предположим, в идиотской инструкции) сказать по-английски, что an electronic device interfaces with power supply through a socket in the wall (дословно: электроприбор взаимодействует с источником энергии через розетку на стене ). Говорю я это к тому, что, в первую очередь, когда говорят об интерфейсе, то речь идет именно об интеракции / совместимости, а не о сериализации / категоризации. Второе часто бывает следствием первого, но первое не обязательно приводит ко второму, возможен обратный вариант, когда инструмент задействованный для интеракции приводит к дивергенции а не унификации.
В AS интерфейс выполняет дополнительно и функцию сериализации, потому что так реализован в языке, но это побочный эффект, более того, с некоторыми негативными последствиями, такими, как, например, два объекта, в принципе, предоставляющие одинаковый реальный интерфейс, предположим, у обоих наличиствует свойство graphics: Sprite и Shape, только потому что формально не реализуют один интерфейс, не могут быть переданы параметром в одну и ту же функцию. EDIT: Вот, кстати, сейчас подумал: заглушка для розетки будет очень хорошим примером использования интерфейса т.как она никоим образом не является электроприбором, но реализует интерфейс розетки-штекера.
__________________
Hell is the possibility of sanity Последний раз редактировалось wvxvw; 06.06.2011 в 21:55. |
Часовой пояс GMT +4, время: 22:24. |
|
« Предыдущая тема | Следующая тема » |
|
|