Форум Flasher.ru - Наследование реализации

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Наследование реализации (http://www.flasher.ru/forum/showthread.php?t=133044)

Наследование реализации

Здравствуйте.

Давно уже мучаюсь следующим вопросом. AS3 поддерживает только наследование типа, между тем в некоторых случаях очень хорошо было бы применить наследование реализации. В этом, в принципе, и состоит вопрос :)

Возмём следующий пример. Пусть имеется базовый класс ItemList, в интерфейс которого входят методы addItem() и deleteItem(). Это – визуальный класс списка, основанный на работе с единичными элементами. Также имеется производный от ItemList класс ListView, который определяет интерфейсный метод setDataProvider(). Этот производный список рассчитан на работу с поставщиком данных, однако в своей внутренней логике использует унаследованные методы addItem() и deleteItem().

Проблема состоит в том, что оставлять эти методы открытыми нехорошо по той причине, что производный класс уже не рассчитан на их прямое использование. В C++ я применил бы закрытое либо защищённое наследование (т.е. наследование реализации), или же композицию.

Композиция – вещь замечательная, более того, она применима и в AS. Но её не всегда удобно использовать. Например в случае того же ListView придётся добавлять используемый ItemList в качестве ребёнка.

Второе решение – определить базовый класс (назовём его CoreItemList), в котором будет содержаться реализация всех интерфейсных, по сути, методов, но они будут объявлены как защищённые. А от него уже наследовать ItemList, объявив в нём публичные обёртки для интерфейсных методов, а также ItemView, используя унаследованные методы в качестве защищённых. Несмотря на свою простоту, это решение кажется мне немного кривоватым :)

Был бы очень рад услышать ваши мысли, касающиеся данного вопроса)

Это называется over-engineered :) Ну, смотрите, если другой програмист возьмет и переопределит ваш метод и не реализует его как нужно - то кто ему виноват, а зачем было лезть, если не знаешь куда? :)
Ну или если совсем не хотите чтобы метод переопределяли - есть final.
ИМО в виду того, что АС медленный делать всякие "обертки" и остальные красивости - чревато тормозами, и просто того не стоит.

Естественно, в некорректной реализации переопределённого метода будт виноваты только кривые руки программиста :) Нет, я не про переопределение.

Я про то, чтобы ограничить унаследованный интерфейс в случае, если производный класс не рассчитан на его прямое использование. Например, вызов ListView.removeItem() приведёт к тому, что будет удалён элемент списка, несмотря на то, что соответствующий элемент данных присутствует в поставщике. Это может привести к последующим ошибкам внутренней логики списка (например, когда от поставщика придёт сообщение об изменении сответствующего элемента данных).

Цитата:

Сообщение от wvxvw (Сообщение 868318)

ИМХО в виду того, что АС медленный делать всякие "обертки" и остальные красивости - чревато тормозами, и просто того не стоит.

Вот и я ж о том же)

Код AS3:

public override function addItem(...):void {

    throw new IllegalOperationError();

}

 

public override function removeItem(...):void {

    throw new IllegalOperationError();

}

 

...

 

private function update(...):void {

    ...

    super.addItem(...);

    ...

    super.removeItem(...);

    ...

}

Единственное что методы в родительском классе нужно делать вроде этого:

Код AS3:

public function addItem(...):void {

    this._addItem(...);

}

Т. е. реализация метода внутри _addItem и все вызовы в пределах класса идут через this._addItem, а не this.addItem.

Цитата:

Сообщение от etc (Сообщение 868341)

Единственное что методы в родительском классе нужно делать вроде этого

Код AS3:

public function addItem(...):void {

    this._addItem(...);

}

можно ли подробнее узнать зачем нужен метод-посредник? Для гибкости кода?
Ничего более путного, чем изменение количества аргументов в голову не приходит. А-ля:

Код AS3:

public function addItem(myVar:int):void {

    this._addItem(myVar);

    //или this._addItem(myVar, 1.5);

}

 

private function _addItem(myVar:int, anotherVar:Number = NaN):void {

    ...

}

опыта мало. увы...

+ ко всему прочему, это ситуация напомнила мне вызовы вроде:
dispatchEvent() -> dispatchEventFunction() -> метод-обработчик
с малопонятным вызовом метода-посредника. Хотя здесь можно списать на нативную реализацию, скрытую за 7-ю печатями.

Цитата:

Сообщение от switcher! (Сообщение 868374)

можно ли подробнее узнать зачем нужен метод-посредник?

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

да, точно. Кстати, очень своевременная информация. Спасибо!

etc, так я всегда, в принципе, и делал. А сейчас что-то вдруг захотелось узнать, нет ли более красивого решения :)
Мне в данном случае не очень нравится вызов дополнительного метода (хотя такое решение часто достаточно гармонично вписывается в логику класса). Но ещё хуже – набор интерфейсных методов, вызывающих безусловные ошибки. В документацию не все заглядывают, а автокомплит не дремлет :) Да и просто как-то это...

Код:

[Deprecated(message="Поскольку-постольку", replacement="сюда-то", since="v 3.42.3.12.123.4.123.123")]

Ммм... Интересно, нужно будет попробовать. Но ведь он же только из доков и автокомплита исключает, правильно я понял? Хотя это уже лучше)

Добавлено через 3 минуты

Цитата:

Сообщение от r_r_f_r (Сообщение 868451)

"v 3.42.3.12.123.4.123.123"

Это с учётом количества изменённых печатных символов? Всегда хотел такую SVN :)