Как создать класс с «глобальными константами»?

Question

[Посторонним В.]

Взялся переписывать проект с процедурного стиля в объектно-ориентированный. Раньше был файл config, где были прописаны все глобальные константы, например, константа ROOT имеет значение $_SERVER['DOCUMENT_ROOT'];

Сейчас решил создать абстрактный класс abstract GlobalConfig и в нём прописать эти константы, чтобы потом тягать значения в другие классы, например так: GlobalConfig::ROOT.

Но теперь проклял всё на свете...

1, Присваивать константе или свойству значение $_SERVER['DOCUMENT_ROOT'] PHP не хочет - должно быть точное значение, видите ли.
2. Прописать метод __construct с присвоением $this->ROOT = $_SERVER['DOCUMENT_ROOT'] тоже нельзя, так как это абстрактный класс.
3. Прописывание __get с возвратом $_SERVER['DOCUMENT_ROOT'] при запросе GlobalConfig::$ROOT не помогает, так как сработает только при создании экземпляра класса (я специально создал абстрактный класс, чтобы не надо было создавать экземпляры), а объявить __get статическим нельзя!

Я просто в ауте. Можно как-то реализовать то, что я задумал??

Answer 1

[Станислав]

abstract class GlobalConfig{
	const ROOT = "DOCUMENT_ROOT";
	public function root(){
		return $_SERVER[self::ROOT];
	}
}
class A extends GlobalConfig{
	public function ttt(){
		return parent::root();
	}
}

$a = new A();
echo $a->ttt();

Вот тебе! Дальше, делай тоже самое, для remote_addr, http_host,http_referer etc.

А если серьезно, выше верно написали, почитай больше про ооп, потом пиши) А то ты пытаешься писать процедурно только с использованием классов :)

Comments

[Посторонним В.]

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

[Роман Белинский]

достойный ответ!

Answer 2

[Посторонним В.]

Нашёл одно интересное решение.
Вы правы - кто говорил, что я фактически не использовал ООП подход, т. к. даже не создавал объекты. Вот, как задача решается с применением синглтона:

class Configurator
{
    static private $_instance = NULL;
    private $ROOT;
    
    private function __construct()
    {
        $this->ROOT = $_SERVER['DOCUMENT_ROOT'];
    }
    
    private function __clone()
    {
    }
    
    public static function getInstance()
    {
        if (is_null(self::$_instance)) {
            self::$_instance = new self;
        }
        return self::$_instance;
    }
    
    public final function __get($name)
    {
        return $this->$name;
    }
}

Далее пишем $config = Configurator::getInstance() и получаем нужные значение обычным способом: $config->ROOT.
Изменить значение переменной извне нельзя, так что это именно то, что я хотел, аналог констант в процедурном интерфейсе. И без создания лишних объектов.

Answer 3

[Роман Белинский]

Конечно можно) Вам скоро ответят на этот вопрос. Я просто не могу обьяснить.

Comments

[enixpp]

Я даже знаю кто ему ответят :)

[Посторонним В.]

Элбек Азимов: троллей не кормим, увы.

[Роман Белинский]

Посторонним В.: но на часть вопроса я ответил.
> Можно как-то реализовать то, что я задумал??
Ответ: Конечно можно)
Я точно знаю, что можно, но не знаю как реализовать, так-то. Я не тролль.

[enixpp]

Посторонним В.: Отвечу все таки:
Зачем вам Абстрактный класс?
Зачем вам Глобальную константу присвоит глобальный переменный ? он же итак глобальный!!
Каков ваш цель от переписанные кода на ООП?
Предположим цель - изучение. Лучше изучите сорцы Фреймворков там много интересного найдете для себя.
Изучите паттерны программирование для начало IoC, Facade, Singleton.
Тогда и придет понимание зачем нужно абстракция, интерфейсы и когда лучше их использовать.
Без понимание паттернов вы не поймете какие возможности дает вам ООП!
а на счет глобального константа - можно но не нужно ! Посмотрите на сорцы Фреймворков одни использует фасады другие DIC для этой цели.

p.s. Надеюсь я ответил на ваш вопрос.

Answer 4

[skynetdev]

А что трейты не пойдут в этом случае??
php.net/manual/ru/language.oop5.traits.php

Comments

[Посторонним В.]

А вот это крутая идея. Спасибо!

[skynetdev]

Посторонним В.: не за что, многие хорошие кодеры не следят за языком и не в курсе новых фишек языка, а зря, а скоро выход PHP7 в этом году, вот там уже все захотят познакомится со всеми вкусняшками

Answer 5

[Хесед]

Если создавать класс, который будет хранить все параметры конфигурации, то зачем его делать абстрактным? Вы собираетесь от него наследоваться и он будет хранить какие-то абстрактные методы, обязательные для переопределения? В таком случае, почему он называется GlobalConfig?

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

Comments

[Посторонним В.]

Этот класс я хочу сделать просто обёрткой, у него не будет экземпляров. Просто где мне надо будет указать путь относительно директории сайта, я пропишу GlobalConfig::ROOT. Или имя сайта буду выводить как Global:Config::SITE_NAME. Но главное - я смогу эти глобальные значения использовать внутри других классов (ведь они глобальные константы и переменные не видят, им приходится всё передавать в конструктор например).

Неужели в ООП это прям таки в корне неправильно? Какие есть альтернативы?

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

[Хесед]

С константами так сделать не получится - на то они и константы, ООП подход тут не при чём. Можно использовать класс Config с полем $data, которое будет содержать массив ключей конфига. В конструкторе определяем динамически заполняемые константы. Создаём метод get($key); который будем вызывать как $a = (new Config)->get('site_name'). Такой вызов работает начиная с PHP 5.4.

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

Готовые решения могут быть разными. Это может быть содранный с phpclub кусок кода, который непонятно как работает и думан вообще для другой задачи. Или это может быть фреймворк. Yii2 или Laravel подошли бы в качестве решения, которое реализуя соглашения, условно "навязывает" правильный подход к проектированию приложения. Там тоже есть место подвигу, но если писать с нуля и вдумчиво курить мануалы, можно получить неплохой результат.