Алексей... хочеться писать своё не вникая в чужой код???

сделайте




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

Алексей Смирнов,

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

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

====

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

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

примеры

if($this->a != $this->b)
{
return $this->c;
}
else
{
return $this->d;
}

в общем случае - сдесь 5 действий.
почему щитывание поля отдельное действие.
потому что, в общем случае, чтобы оно не означало, сегодня это ....например состояние обьекта - готов или не готов к работе, завтра за этим можем стоять логика, что уже не одним флагом а несколькими определяется.
поэтому если $this->f - флаг готовности, то лучше делать

function is_active()
{
return (bool) $this->f;
}

завтра если у потомка добавиться ещо один флаг, $this->ff и готовность будет другой, будет
достаточно переписать этот метод, а не лопатить весь код, и менять везде.

с практической точки зрения - подобное должно быть для всех публичных свойств - либо функция, если оно больше подходит по логике - как проверка готовности, либо __set __get
с защищёными методами _set_field_a($newvalue) _get_field_a()

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

1) нехотите париться о передаче обьекта ...
тут надо определиться.
есть базовые ситуации.
1.1 - этот глобальный обьект - это обьект связаный с текущей авторизацией/правами в системе итд.
тогда решением хорошим будет.
логика - есть понятие текущая авторизация === есть класс который за это отвечает.
все кому надо чтото из этого глобального понятия используют класс.

решение - class Auth {} в нем изначально инициализируеться все, и потом все кому надо глобально чтото - используют , напр. Auth::current_user(), Auth::is_anonymous(), Auth::expiration_time(), Auth::user()->name - если поле юзер содержит обьект текущего пользователя.

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


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

1.3 это глобальное связано с поведением - например, наш класс1 - это клас через который мы сохраняем файлы, а класс2 - это обработчик который физически сохраняет файл, в базе данных, а есть класс2.1 - он сохраняет на фтп сервер, а класс2.2 вообще хитро ещо кудато сует.
это называеться драйвер.

тогда обычно



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

надеюсь мой эпос поможет на пути создания и красивой и удобной архитектуры.