OOPHP подходящая альтернатива синглтон?

Question

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

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

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

Будет ли это жизнеспособной альтернативой синглтону и решит ли он проблемы тестирования, которые он вызывает? Это все теория, я еще ничего не начал кодировать,

Любые мысли или советы с благодарностью. Спасибо.

Answer 1

Я думаю, что лучший способ - это иметь объект 'configuration', который будет передан конструкторам всех ваших других классов. Итак, почти что-то похожее на синглтон, за исключением того, что оно явно создано и передано только классам, которые в этом нуждаются. Этот подход обычно называется внедрение зависимостей .

Answer 2

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

Используйте файл начальной загрузки или файл инициализации. Он находится в корне сайта с соответствующим разрешением и защитой от прямого доступа.

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

Например:

// OBJECT CREATION
$Config = new Configuration();
$User = new User();

Тогда внутри классов, которым требуются эти объекты:

public function __construct($id = NULL) {
    global $Config; // DEPENDENCY INJECTION SOUNDS LIKE AN ADDICTION!

    if($Config->allow_something) {
        $this->can_do_something = true;
    }

    if(NULL !== $id) {
        $this->load_record($id);
    }
}

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

Кроме того, наличие статического класса Database было очень полезно. У меня нет объектов, о которых мне нужно беспокоиться, я могу просто позвонить $row = DB::select_row($sql_statement);; проверьте класс PhpConsole.

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

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

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

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