Куда девать функции?

[Духовность™]

Куда девать функции?

Есть самописная функция foo, применяется в классе fooClass.

Куда её деть?

1. Сделать private методом класса fooClass
2. Сделать public static методом класса-пакета String (такого пакета у меня ещё не существует)
3. Оставить в наборе функций для системы functions.php

 

[Adelf]

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

 

[Beavis]

triumvirat
ну ты определись к какой сущности относится эта функция

 

[Духовность™]

Adelf

если она делает какое-то действие со строкой, которое нельзя точно ассоциировать только с данным классом

Функция str_replace_one - это вот что? Это второе? Или первое? Часто ли тебе приходилось использовать функцию str_replace_one? Так же и мне. Фактически - это самодостаточная функция для работы со строкой. А по хорошему она нужна (ПОКА) только в классе.

 

[Beavis]

если у тебя нет и не предвидится объекта для работы со строками, то

3. Оставить в наборе функций для системы functions.php

 

[Духовность™]

Beavis
А смысл? Когда мне нужно будет класс перенести в другой проект, придётся тягать ещё и из проекта все подключаемые библиотеки.

как вариант рассматриваю функцию в файле класса:

if (!function_exists('str_replace_once'))
{
    function str_replace_once($search, $replace, $subject) {
        // .... 
    }
}

 

[Adelf]

str_replace_one - это второе. К классу отношения не имеет никакого.

Я понимаю твою ситуацию В таких случаях я скрепя зубами переношу их из класса куда-нибудь в functions.inc.php . Потому что переносить не хочется, но по правильному - надо.

 

[Lightning]

Оставь пока как есть. Потом, если понадобится, переместишь. Зачем мосх ломать?

 

[x-yuri]

почему надо? Если удобно их держать в классе и они никому больше не нужны. А вынести всегда успеешь

 

[nirex]

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

 

[Alexandre]

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

$res = Math:arcsin($ugol);
но не так:
$res = Funct:arcsin($ugol);

ИМХО - делай чтоб было интуитивно понятно

 

[Beavis]

triumvirat
а ты хочешь создать класс, который вообще чтоль ни от чего не зависит?))) так не бывает)

 

[Духовность™]

так не бывает)

бывает.

 

[findnext]

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

$res = Math::arcsin($ugol);
$date = Format::date($date)

 

[Духовность™]

У меня все такие функции разделены по полочкам

Я поступил так же в JS. Но там уже есть примитивные объекты. Поэтому там нечто подобное не вопрос:

String.prototype.isEmpty = function(){ /**/ }

alert(var.isEmpty())

В PHP, в котором ООПшность была притянута за уши, объединять функции в класс типа String или Math - глупость. Ибо

Math::arcsin($ugol);

абсолютно ничем не отличается от

math_arcsin($ugol);

А

Format::date($date)

должен вызываться как

$date::format();

 

[AmdY]

если она используется только в этом классе, сделай её protected/private методом данного класса, ни к коем случае не public, чтобы не было иллюзий, что она ещё где-то понадобится.
выносить отдельно в подобной ситуации - бред.
и не нужно бояться немножко поговнокодить, главное ставь /** @todo убрать этот говнокод нахрен */

 

[Adelf]

и не нужно бояться немножко поговнокодить, главное ставь /** @todo убрать этот говнокод нахрен */

Да здравствуют вечные @todo?

Не одобряю я такое у себя.

 

[whirlwind]

Исходя из так нелюбимых тут некоторыми местными личностями ооп постулатов, можно сделать следующие выводы относительно вопроса "когда нужно создавать класс":

1. Когда есть что скрывать
2. Когда в перспективе видна необходимость замены одних алгоритмов другими
3. Когда в предполагается наличие некоторого количества типов со схожим поведением

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

-~{}~ 06.10.09 23:36:

PS. Тока прцедурщики в споре налегают на то что нет разницы как записывать в плане вызовов и поэтому ооп не оправдано, а оопешники на то, что процедурное лишает де нас таких полезных возможностей как инкапсуляция, полиморфизм и наследование. Вот и получается спор слепого с глухим

 

[Lightning]

whirlwind
Ты хоть топик прочитал перед тем как постить?

 

[whirlwind]

А что тебя смущает в моем посте? Ты не понял что я высказался против

2. Сделать public static методом класса-пакета String (такого пакета у меня ещё не существует)
3. Оставить в наборе функций для системы functions.php

ну тогда может пора начать читать более вдумчиво?