Форум 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=148709)

использовать или не использовать интерфейсы

Заметил за собою, что во Флеше, уже который раз предпочитаю использовать возможность передачи функции, нежели создание интерфейса (хотя в других языках, где невозможно передавать функции как параметр, достаточно юзаю интерфейсы).
Например класс Х работает с другими классами у которых есть функция DoSomeThing. Можно

Код AS3:

public interface iprocessor {

        function DoSomeThing(par:int):void;

}

public class X {

        function setProcessor(o:iprocessor){

                ....

        }

}

т.е. как в других языках.
А можно

Код AS3:

public class X {

        function setProcessor(f:Function){

                ....

        }

}

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

Передаю то, что нужно для задачи. К функциям пишу комментарий типа: addChild->DisplayObject->DisplayObject.

Зависит от задачи. Если предполагается, что нужна функция (например, какая-нибудь filterFunction), то передается функция. Если предполагается работа именно с классом, то интерфейс. У того же процессора, помимо DoSomeThing могут быть и параметры, которые необходимо настроить.

Ответы расплывчаты. Я так понимаю вы тоже как я использууете.
Вот к примеру для Undo что я делаю. Все классы в которых можно сделать Undo должны иметь функции undo и redo.
Какое решение бы вы использовали.
интерфейс или две функции??

Можно и наследование использовать. Если нет возможности, то интерфейс.

Вопросы не менее расплывчаты. Какое отношение некие классы имеют к undo/redo? Я бы реализовал undo/redo командами, и они бы имели интерфейс.

Цитата:

Сообщение от passertm (Сообщение 962994)

Заметил за собою, что во Флеше, уже который раз предпочитаю использовать возможность передачи функции, нежели создание интерфейса

А потом я читаю твой код. И он делает меня печальным. Я становлюсь раздражительным, потому что документацию ты тоже не подготовил и даже следа твоего не осталось. А что касается последнего, так и слава богу.

Немного умственных потуг принесут гораздо большее удовлетворение. С одной стороны - обеспеченные тылы, с другой - светлое будущее. Не передавай ссылки на функции там, где не нужно этого делать.

Цитата:

Так вот, второй метод проще

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

Только беда в том, что на дворе 2011 год, а в actionScript3 до сих пор параметры функций не типизируются во время компиляции (в haXe это было и есть даже для flashplayer8), как, врочем и генериков до сих пор нет :(

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

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

Цитата:

Сообщение от iNils (Сообщение 963042)

Можно и наследование использовать. Если нет возможности, то интерфейс.

Извините, не согласен. Насколько я знаю, должно быть как раз наоборот. Не буду долго объяснять, просто процитирую труд Гаммы, Хелма и других товарищей из Gang Of Four "Design Patterns:Elements of Reusable Object-Oriented Software":

Цитата:

предпочитайте композицию наследованию класса

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

Цитата:

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

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

Тут тоже процитирую GoF:

Цитата:

принцип объектно-ориентированного проектирования для повторного использования: программи-
руйте в соответствии с интерфейсом, а не с реализацией.

Цитата:

Тут тоже процитирую GoF:
принцип объектно-ориентированного проектирования для повторного использования: программи-
руйте в соответствии с интерфейсом, а не с реализацией.

ИМХО это высказывание не в тему.

Передавая классу функцию Вы завязываете этот класс на СИГНАТУРУ функции, а НЕ на ее реализацию
т.е. просто вместо передачи 1-го интерфейса с 3-мя методами вы передаете 3 мелких ИНТЕРФЕЙСА-функции
А как известно из принципов SOLID "лучше несколько мелких интерфейсов, чем один большой"
Так что все с точностью наоборот :)

Цитата:

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

Можно и наследование использовать. Если нет возможности, то интерфейс.

Цитата:

предпочитайте композицию наследованию класса

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