Один файл на функцию ... правда?

Question

Я относительно новичок в Flex / ActionScript, но я использовал шаблон создания одного файла для каждой функции в моем пакете утилит - имя файла совпадает с именем функции. Как если бы файл был convertTime.as:

package util{
    public function convertTime(s:String):Date{
        ...
    }
}

Таким образом, я могу легко импортировать функцию, выполнив:

import util.convertTime;
...
convertTime(...);

Мне нравится этот способ лучше, чем импортировать объект класса и затем вызывать статические методы, свисающие с него, например:

import util.Util;
...
Util.convertTime(...);

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

Обновление: после некоторых исследований я также разместил свой собственный ответ ниже.

Answer 1

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

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

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

Answer 2

В конце концов я наткнулся на некоторые другие альтернативы и решил поделиться ими здесь.

Альтернатива 1 - использовать наследование

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

Альтернатива 2 - псевдоним методы

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

import mx.binding.utils.BindingUtils;
var bind:Function = BindingUtils.bindProperty;

Теперь вы можете просто позвонить

bind(...);

а не длинный

BindingUtils.bindProperty(...);

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

Альтернатива 3 - использование включает

Как описано в этом блоге flexonrails , вы можете использовать include для имитации миксина в ActionScript. include отличается от импорта тем, что все, что он делает, копирует весь файл, из которого вы включаете, и вставляете его в место, куда вы его включаете. Таким образом, он полностью не обрабатывает проблемы с пространством имен, вы не можете впоследствии ссылаться на его полное имя пути, как при импорте, если у вас конфликтующие имена, вы сами справляетесь с этим. Также в отличие от импорта, он создает разные копии одного и того же кода. Но то, что вы можете сделать с этим, это поместить любое количество функций в файл и включить их в область действия класса или функции в другом файле. Пример:

// util/time_utils.as
function convertTime(..){
   ...
}
function convertDate(..){
   ...
}

Включать:

include 'util/time_util.as';  // this is always a relative path
...
convertTime(...);

Answer 3

@ an0nym0usc0ward

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

Любой, кто действительно понимает ООП, не будет достаточно наивен, чтобы думать, что одобренная и документированная форма ООП - это единственный возможный способ возразить вашему коду.

РЕДАКТИРОВАТЬ: Это должен был быть комментарий в ответ на грубый комментарий an0nym0usc0ward, говорящий ему изучать ООП. Но, наверное, я набрал его не в том поле:)