Как глобально хранить объект?

Question

[cheremushkin]

У меня в коде есть несколько объектов, методы которых мне нужны практически во всех остальных частях программы. Но создавать все время заново эти объекты во всех функциях я не хочу; прописывать global тоже не нравится. В константах тоже не получается хранить, там только скаляр. Но, может, существует другое решение?

Конечно, можно обойтись вариантом вызова методов через :: (static), но мне бы хотелось найти более красивое решение.

Answer 1

[serso]

Если это утилитные методы (сортировка, форматирование и т.д.), то нормальная практика — делать их статичными.

Comments

[cheremushkin]

Да, это в принципе, такие методы. Например, у меня есть класс Math в котором у меня некоторые методы для математических вычислений. Эти вычисления могут потребоваться от куда угодно.

Я не совсем уверен, когда стоит и когда не стоит использовать статичные методы. С одной стороны можно сделать все методы такими и вообще не создавать объектов, что может показаться удобным, но как-то теряется дух ОО программирования (ведь самого объекта-то и нет).

[Назар Мокринский]

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

[serso]

Именно для этого и нужны статичные методы. Если брать пример из Java (увы в php не силён), то там есть класс java.util.Math, в котором имеются утилитные методы public static double floor(double a), public static double toDegrees(double angrad) и т.д., которые как раз и являются статичными.

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

[denver]

Дух ОО программирования говорит что если объекта нет (а Math это не объект, его методы никак не связаны) то и не нужно объекта. Чем плохи просто функции? Если угодно объединить их, то под одним неймспейсом.
Статичные методы не надо использовать практически всегда. Не зло, но и не для того они существуют, чтобы делать классы только со статичными.

[denver]

Не буду спорить с serso (спасибо за примеры), но по-моему java.util.Math попахивает. Ну не ооп это, какое-то классово-ориентированное П :)

[Vampiro]

"Вам шашечки, или ехать?"(с)

Объединение функций в один класс и вызов их через статику удобен по меньшей мере тем, что не надо делать include/use. Класс сам загрузится через автолоадер. Кроме того, для стороннего программиста будет проще изучать такой код — он набьет «Math::» и автоподстановка ему подскажет варианты с аргументами, когда ему будет необходимо исправить пару строк в вашем коде. Возможно это будете Вы сами через 4 года =)

[cheremushkin]

serso, denver, Vampiro: спасибо за ответы. Я думаю, что я лучше не буду просто так создавать классы, а функции буду объединять в неймспейсы (закину их в одну папку и напишу скриптик подгрузки всех сразу). Но я, к сожалению, забыл про один важный момент — свойства. Неймспейсы не влияют на переменные. Таким образом остается либо статичное использование в классах, либо прописывать global (вызывать через массив), я прав?

Опишу сейчас ситуацию: у меня в скрипте изначально работает только класс Engine, который, следуя из названия, обеспечивает работу всего (дальше подключаются другие классы и модули, но с ними нет проблем). Так вот, с методами-то я разобрался, но есть несколько свойств у этого класса, которые я использую везде (к примеру, у меня есть свойство Engine::$smarty, которое хранит объект шаблонизатора Smarty; есть еще и другие свойства). Так вот в константах нельзя хранить такие данные. Остается только вариант прописывать global?

[Назар Мокринский]

Если категорически не хотите global — повторюсь о статических переменных.
Простой пример:

function vars ($var, $value = null) {
    static $array;
    if ($value === null) {
        return $array[$var];
    } else {
        return $array[$var] = $value;
    }
}

Можете создать такую функцию в текущем пространстве имен.

[cheremushkin]

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

[Назар Мокринский]

Всё верно, я и подал пример функции, которая сохраняет/выдает результат.
Ещё более извращенный способ — хранение в статических переменных функций ссылки на статическую переменную в функции типа той, которую я написал. Тогда нужно будет вызывать функцию только раз, но тогда уже проще использовать обычный объект.

[cheremushkin]

nazarpc, я подумал, поразмыслил, и реализовал хранение вашим методом. Только, немного поправив функцию и ее смысл (не знаю, насколько это все правильно, я только учусь).

Предыстория: мне тут советовали разные паттерны проектирования, я почитал о них и в итоге я понял, что для меня более всего в данный моммент подходит «Фасад». В общем, у меня есть объект $facade, который является, как Вы понимаете, фасадом.

Для работы системы я использую, как я говорил раньше, Smarty. Так вот, я создал в классе Facade свойство vars (private, array) и добавил метод vars($var, $value = false) (public), который сохраняет в свойстве-массиве vars новый элемент с индексом $var и значением $value, если оно не false и такого индекса нет. Если такой индекс есть, но переданное значение на false, то возвращается значение $this->vars[$var]. Это единственный публичный метод в классе. Когда я создаю экземпляры сложных частей сайта (модулей), я передаю им этот объект ($module = new ModuleName($this)) и потом, в конструкторе создаваемого объекта, сохраняю в его (нового объекта) приватные свойства объект Smarty. А, собственно, в чем смысл, ведь легче сделать static свойства, но в моем случае исходные значения останутся неизменными в любом случае, т.к. я предоставляю права только на чтение.

[cheremushkin]

Ха, это получается я «встроил» шаблон проектирования «Реестр» в систему, только без явного создания объекта. Но на всякий случай я отделю его, т.к. в классе Facade есть публичный метод для запуска системы, что может быть не безопасно.

Answer 2

[Назар Мокринский]

Вам нужно связать объект с определёнными участками кода, и вы тут же оборвали возможные технические способы.
Можете попробовать хранить в кеше APC (функции apc_store()/apc_fetch()) — но не уверен в том, правильно ли он будет хранить объекты. Да и между запросами такой кеш будет сохранять данные.

Answer 3

[EugeneOZ]

Статические методы, переменные это тоже самое, что и GLOBAL, и воняет оно абсолютно также. И к ООП это не имеет отношения — это процедурное программирование.

Если хотите именно ООП, делайте как принято в ООП — передавайте объект (dependency injection) или используйте трейт, его можно просто use и всё.

И учитывайте — если объект нужен везде, просто потому, что у него много разных методов, то нужно проверить, одну ли ответственность выполняет этот объект (читайте про SOLID и принцип единой ответственности).

Answer 4

[Igor]

Шаблон проектирования Реестр

Comments

[Роман Гоголев]

Пример из ZF

Answer 5

[DanielWolf]

Паттерн Одиночка (Singleton)
http://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)

а точнее Пул одиночек (Multiton / Registry of singletons).

Answer 6

[Анатолий]

Если вам нужен обьект как сущность, то создавайте везде, если у вас класс как набор функций, то делайте статику, а если тот же обтект как сущность вам нужен лишь один раз, то уж глобал либо синглтон. Все просто =)

Answer 7

[Вячеслав Плиско]

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

Советую заглянуть в статью wiki.agiledev.ru/doku.php?id=ooad:dependency_injection