Можно ли когда-либо иметь класс в виде набора методов и без свойств?

Question

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

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

Рассматривать их как плоский библиотечный файл кажется слишком простым из-за отсутствия лучшего слова.

Какова лучшая практика для этого?

Answer 1

Проверьте пространства имен:

http://www.php.net/manual/en/language.namespaces.rationale.php

Обертывание их в бесполезный класс является обходной реализацией концепции пространства имен.Эта концепция позволяет избежать коллизий с другими функциями в крупных проектах или при использовании плагинов / модулей.

РЕДАКТИРОВАТЬ

Застрял в PHP 5.2?

Нет ничего плохого в использовании отдельных файлов для организации служебных функций.Обязательно документируйте их с комментариями, чтобы не получить bunchafunctions.php, файл с процедурным кодом сомнительной цели в 20 000.

В префиксах тоже нет ничего плохого.Использование префиксов - это еще один способ организации функций общего назначения, но обязательно избегайте этих «псевдо-пространств имен», уже зарезервированных языком.В частности, "__" зарезервирован как префикс PHP [ ссылка ].Чтобы быть особенно осторожным, вы также можете обернуть ваши объявления функций в function_exists проверках, если вас беспокоят конфликтующие функции из других библиотек:

if (!function_exists('myFunction')) {
    function myFunction() {
            //code
    }
}

Вы также можете пересмотреть структуру вашего объекта, возможно,эти вспомогательные функции были бы более подходящими в качестве методов базового класса, которые могут расширять все другие объекты.Взгляните на наследование: http://www.php.net/manual/en/language.oop5.inheritance.php. Шаблон базового класса является распространенным и очень полезным:

abstract class baseObject {
    protected function doSomething () {
        print 'foo bar';
    }
    public function getSomething () {
        return 'bar foo';
    }
}

class foo extends baseObject {
    public function bar () {
        $this->doSomething();
    }
}

$myObject = new foo();
$myObject->bar();
echo $myObject->getSomething();

Вы можете поэкспериментировать с приведенным выше кодом здесь: http://codepad.org/neRtgkcQ

Answer 2

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

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

Answer 3

Я бы использовал классы с static методами в таком случае:

class Tools {

    static public function myMethod() {
         return 1*1;
    }

}

echo Tools::myMethod();

РЕДАКТИРОВАТЬ

Как уже упоминалось Крисом и yes123: если хостеруже работает PHP 5.3 + , вам следует рассмотреть возможность использования namespace.Я бы порекомендовал прочитать статью Мэтью Вейера О'Пинни Почему PHP Namespace Matter , если вы не уверены, стоит ли переходить на пространства имен.

EDIT

Хотя те, кто обобщал использование статических методов как «плохую практику» или «бессмыслицу», не объясняли почему они считают это таковым - что, по моему мнению, было бы более конструктивным- они все еще заставили меня переосмыслить и перечитать.

Типичными аргументами будет то, что статические методы могут создавать зависимости и из-за этого могут сделать невозможным модульное тестирование и переименование классов.

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

Даже если используется модульное тестирование, можно избежать создания зависимостей статических методов с помощью $var::myMethod().Таким образом, вы все еще можете использовать насмешки и переименовать класс ...

Тем не менее я пришел к выводу, что мой ответ слишком обобщен.

Думаю, мне лучше написать: Это зависит .

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

Я проголосовал за ответ Криса сейчас.Он уже охватывает большинство технических возможностей и должен служить вам хорошо.

Answer 4

Рассматривая их как класс, вы получаете преимущество пространства имен, хотя вы могли бы добиться того же результата, если префиксировать их, как в PHP, с помощью функций array_*.Поскольку у вас нет никаких свойств, это в основном означает, что все ваши методы являются статическими (как Class::method()).Это не редкость в Java.

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

РЕДАКТИРОВАТЬ: Если доступен PHP 5.3+, функция пространства имен является идеальной.Однако версии PHP по-прежнему отстают на многих хостах и ​​серверах, особенно на тех, которые используют стабильные корпоративные дистрибутивы Linux.

Answer 5

Написание набора «общих, но связанных» функций обычно является плохой идеей.Скорее всего, вы не видите достаточно ясную проблему для создания правильных объектов.

Это плохая идея не потому, что это «не идеальный ООП».Это вовсе не ООП.

«Шаблон базового класса», предложенный Крисом, - еще одна плохая идея, которую Google предлагает: «отдавать предпочтение композиции по наследованию».

"быть очень осторожным" с помощью function_exists ('myFunction') - не идея.Это кошмар.Такого рода кодов в настоящее время избегают даже в современном javascript ...

Answer 6

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

Answer 7

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

Мое нынешнее чувство здесь - «Хьюстон, у нас проблема».

Answer 8

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

1. один файл со всеми функциями
2. один файл с каждой функцией в качестве собственного класса
3. один массивный класс утилит со всеми методами
4. один файл utils.php, содержащий файлы в папке utils с каждой функцией в отдельном файле