Выдается ошибка, если protected доступ к функции, при реализации интерфейса

[Alexmody]

Подскажите, почему при реализации функций интерфейса,
если реализуемой функции присвоить модификатор доступа protected или private,
то выводится ошибка? Если же public - все ок.

Я например, хочу реализовать функцию интерфейса, но при этом, чтобы ее мог заместить (override) наследуемый класс, а для пользователя эта функция была бы недоступна.

//Интерфейс:
public interface IAction
{
function init():void;
function destroy():void;
}

//Реализация
package
{
public class Base implements IAction
{
public function Base() {
}

//Выдает ошибку, если модификатор доступа к функции protected
protected function init():void {
}

public function destroy():void {
}
}
}

[СлаваRa]

interface (http://help.adobe.com/ru_RU/FlashPlatform/reference/actionscript/3/statements.html#interface)

"Определения методов интерфейса не могут иметь таких атрибутов, как public или private, но реализованные методы должны быть отмечены как public в определении класса, реализующего интерфейс."

[Alexmody]

Да, но как тогда быть если: хочу реализовать функцию интерфейса, но при этом, чтобы ее мог заместить (override) наследуемый класс, а для пользователя эта функция была бы недоступна?

[caseyryan]

Никак. Это же абсурдно по самой сути. Зачем тогда нужен интерфейс?

[Alexmody]

Интерфейс нужен, чтобы определить/реализовать в классе четкий набор функций, для программиста. (чтобы программист не забыл реализовать все функции). Напр. в моем случае, мне нужно скрыть реализуемую ф-ю для конечного пользователя (тот кто будет использовать, а не расширять данный класс).

[GBee]

То есть вы пытаетесь заставить программиста интерфейсом заполнить необходимые методы? Интерфейс не для этого. В вашем случае это какое-то тз.

[etc]

В интерфейсе описываются только публичные свойства и методы. Вам необходим базовый класс с пустым или непустым protected методом. Впрочем, я не очень понимаю, причем тут интерфейс, если ни protected, ни private методы снаружи вызвать нельзя.

[Deimos747]

К сожалению в AS3 нет абстрактных методов, поэтому могу вам только посоветовать использовать следующую конструкцию:
protecte function overrideMe(): void
{
throw new Error("Abstract method, override me!");
}

[Александр Мостовой]

Обозначить доступные и недоступные для override протектид методы вы можете при помощи атрибута final.
Т.е. те у которых нет final - доступны для override

[Alexmody]

Хорошо, тогда подскажите первоочередную задачу, для которых созданы интерфейсы?

Интерфейс — это набор объявлений методов, который позволяет несвязанным объектам взаимодействовать
друг с другом.

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

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

К сожалению в AS3 нет абстрактных методов, поэтому могу вам только посоветовать использовать следующую конструкцию:
protecte function overrideMe(): void
{
throw new Error("Abstract method, override me!");
}

Да, для решения выше поставленной задачи так и делаю, видимо мне нужно более точно понять, для чего вообще созданы интерфейсы и какова их задача, к сожалению читал о них в различных книгах по action script 3 и там постоянно приводились примеры описывающие вышеприведенную ( в данном посте) взаимосвязь.

[Wolsh]

и там постоянно приводились примеры описывающие вышеприведенную ( в данном посте) взаимосвязь.Какую? Памятка для программиста? Что-то я сомневаюсь, что это можно показать примером кода)))))
Вы еще раз задумайтесь. Нельзя вызвать у объекта методы с модификаторами private и protected. Какой был бы смысл упоминать их в интерфейсе? Интерфейс это взаимодействие. Он говорит что вот у этого объекта можно вызвать такой-то метод. А если его нельзя вызвать, то его и не может быть в интерфейсе.
Как наличие или отсутствие собственных, внутренних методов может помешать "созданию системы и взаимодействию"? Эти методы — личное дело каждого, недоступное для других. Они никак не участвуют ни в каких системах и взаимодействиях.

[iflamberg]

Для чего нужны интерфейсы? Ну, представьте, что у вас есть несколько классов, которые не наследуют друг-друга в силу очень разной их природы(или в силу того, что в as3 нет множественного наследования), но, экземпляры которых надо все таки передавать в какую-то функцию, чтобы выполнить определенное дейсвие, общее для всех них. Как передать их в эту функцию? Как Object?

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

package engine {
public interface IPauseable {
function pause ():void;
function unpause ():void;
}
}

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

var l:int = scene.numChildren;
while (l--){
var cur:Sprite = scene.getChildAt(l);
if (cur is IPausable) IPausable(cur).pause();
}

[Alexmody]

Wolsh
Нет, книги типа Action Script 3: подробное руководство и пр.

iflamberg
Да, таким образом я и использую интерфейсы, т.е. объединяю едиными функциями различные объекты для конкретного функционала.
Кстати, тот же ваш пример, если заменить интерфейс базовым классом, получается почти то же самое...?
С другой стороны, если использовать больше композицию (без или с минимум наследования), тогда да интерфейсы приобретают большую значимость.

[caseyryan]

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

[Wolsh]

Ладно, я окончательно потерял нить диалога (я Вам про одно, Вы мне о чем-то вообще своем отвечаете.. или это вопрос, нет ли у меня книги Мука? Есть).
Кстати, тот же ваш пример, если заменить интерфейс базовым классом, получается почти то же самое...?Попробуйте написать "базовый" класс и унаследовать от него классы, расширяющие ТекстФилд, Спрайт и Битмап. Если получится, то — да, то же самое.
если использовать больше композицию (без или с минимум наследования), тогда да интерфейсы приобретают большую значимость.Естественно, ведь интерфейсы не имеют никакого отношения к классам и наследованию. Они описывают только публичные методы только экземпляров.

[Alexmody]

Wolsh

>>Попробуйте написать "базовый" класс и унаследовать от него классы, расширяющие ТекстФилд, Спрайт и Битмап. Если получится, то — да, то же самое.

Если взять в контексте С++, где есть множественное наследование, и особо не прибегать к композиции, то тогда какова в данном случае значимость и функционал интерфейсов? Если не ошибаюсь в С++ нет интерфейсов, вероятно потому что есть множественное наследование...

Ниже, вы конечно ответили частично на этот вопрос но все же:
>>Естественно, ведь интерфейсы не имеют никакого отношения к классам и наследованию. Они описывают только публичные методы только экземпляров.[/QUOTE]

[caseyryan]

Если взять в контексте С++, где есть множественное наследование, и особо не прибегать к композиции, то тогда какова в данном случае значимость и функционал интерфейсов? Если не ошибаюсь в С++ нет интерфейсов, вероятно потому что есть множественное наследование...
as3 не С++, и не нужно сравнивать. Да в С++ есть множественное наследование, и это не есть гуд. Конечно пути обхода придумываются, но тем не менее коллизии возникают. А что если разные классы имеют разную имплементацию одного и того же метода? Какую выбрать? Это взрыв мозга для компилятора. Поэтому интерфейсы - решение более разумное, чем множественное наследование.

[iflamberg]

В as3 интерфейсы выполняют ту же роль, что абстрактные классы и множественное наследование в спп. Все.

[Black Soviet]

iflamberg
var l:int = scene.numChildren;
while (l--){
var cur:Sprite = scene.getChildAt(l);
if (cur is IPausable) IPausable(cur).pause();
}
Но эту же задачу можно реализовать и без участия интерфейса, если в каждом классе, экземпляры которого находятся на сцене, описать метод pause().

[Wolsh]

Да? И как Вы докажете компилятору, что у этих эеземпляров действительно есть метод pause?

[Black Soviet]

Wolsh
Да, вы правы, никак.

Поясните только почему
IPausable(cur).pause();
,а не
cur.pause();

[Alexmody]

as3 не С++, и не нужно сравнивать. Да в С++ есть множественное наследование, и это не есть гуд. Конечно пути обхода придумываются, но тем не менее коллизии возникают. А что если разные классы имеют разную имплементацию одного и того же метода? Какую выбрать?

Раздел The diamond problem:
http://en.wikipedia.org/wiki/Multiple_inheritance

Да? И как Вы докажете компилятору, что у этих эеземпляров действительно есть метод pause?

Ну вроде бы кастомизацией типа, т.е. указывается тип данных, а в скобочках объект кастомизации:
IPausable(cur).pause();

[iflamberg]

Wolsh
Да, вы правы, никак.

Поясните только почему
IPausable(cur).pause();
,а не
cur.pause();
Потому что cur у меня Sprite, у котого нет функции pause(). Я привожу его к типу IPausable, у котого такая функция есть. А перед этим проверяю, дейсвительно он относится к этому типу. Потому что на сцене могут быть и просто Sprite, которые не анимированы и которых останавливать на паузу смысла нет.

Да, можно обойтись без интерфейса.

var l:int = scene.numChildren;
while (l--){
var cur:* = scene.getChildAt(l);
if (cur.pause) cur.pause();
}

Можно много без чего обойтись. Без private и protected членов класса. Или без сеттеров-геттеров. Все эти финтифлюшки по большому счету для удобства работы в команде и читабельности кода.

[caseyryan]

Раздел The diamond problem:
http://en.wikipedia.org/wiki/Multiple_inheritance

Я знаю это ) И как обходят знаю. И тем не менее это кривой подход. Не смотря на всю крутость и развитость С++, есть в нем и серьезные недостатки. Множественное наследование я считаю недостатком. Ну, это лично мое мнение.
Все эти финтифлюшки по большому счету для удобства работы в команде и читабельности кода.
Я бы так не сказал. Работа в команде тут вообще ни при чем. Даже если один работает, все равно все это нужно для правильной организации проекта.

[etc]

Все эти финтифлюшки по большому счету для удобства работы в команде и читабельности кода.

И только? Неожиданно.

[Babylon]

Я то же считаю множественное наследование недостатком, но и с недостатками жить можно :)

Добавлено через 3 минуты
Проектирование и программирование это разные специализации. Иногда на первое попросту время нет. Да и не все заказчики понимают необходимость проектирования и согласования. Поэтому работает принцип - любой "г/к" за ваши деньги.