Мне надо написать класс для обработки некоторых данных (HTML и не только) требования к нему - простота использования. Идеальный вариант это все сделать через статические методы, но мне надо подгружать настройки для этого класса, сделать как то так не получается: Код (PHP): public static $config = include('config.php'); // а include возвращает массив с настройками Какого то метода, который будет выполняться при подгрузке класса (что бы в него запихнуть подключение настроек) на сколько мне известно нет, а выполнять подгрузку отдельно не хочется. Решил сделать так, использовать не статические методы, но при этом что бы они работали как статические, т.е. типа: Код (PHP): class cls { public static $data; public $config; public function fns() { // ..... внутри ни где не используется $this, // если все же нужен объект, мы создаем его и сохраняем в self::$data // а при создании объекта как раз будет срабатывать конструктор, который будет подгружать настройки } } и с одной стороны я могу создать объект класса и работать с ним: Код (PHP): $obj = new cls(); $obj->fns(); С другой стороны использовать на прямую как статику: Код (PHP): cls::fns(); собственно несколько вопросов, они достаточно глупые, первый, вообще как такой подход, нет ли в нем слабых мест? Может такой подход тормозит или что-то такое. Второй еще глупее, может можно прописать что-то, что бы РНР учитывал что методы не статические, но работают как статически, явно указать на это. И в целом как подход?
1. Если ты вызываешь не статический метод как статический, то пых выдаст предупреждение: Strict Standards: Non-static method should not be called statically. Оно конечно не fatal error, но забивать не стоит. 2. Если ты вызовешь статический метод как не статический, то пых деликатно промолчит, если конечно это возможно: несмотря на вызов метода как обычного, $this по прежнему там не будет. Вывод: если тебе нужно вызывать методы как статические, то изначально так их и объявляй. Потом уже можешь к ним обращаться как к обычным методам. Уверен, адепты экономии на спичках уже посчитали, что такой подход обходится нам в целых сто микросекунд, но на то они и адепты. По косякам. Заморочки тут могут возникнуть точно такие же как у глобальных переменных. Если ты уверен, что ни где более конфиг не перезагрузится, то пользуйся. http://sandbox.onlinephpfunctions.com/code/634f5848890b2c1e ... a83dd73d16 удобная штука для быстрого теста подобных заморочек.
хм.. я ни каких ошибок не получал, при этом ini_set -> display_errors -> 1 Точно будет какое-нибудь предупреждение? потому что на сколько я помню, точно так же можно в С++ вызывать не статические методы и это нормально. ну то что $this не будет, я в курсе, учитываю это. А вот это интересно, об этом я что то даже не подумал. Хотя конечно мне бы больше подходили НЕ статические методы. и за ссылку спасибо.
Мешать статику и не статику не нужно, PHP это не JS, где такое является нормой. Гляди, как такие вещи сделаны у меня: 1) Есть статический класс, в нем поле Data. 2) В него нужно подгрузить массив из внешнего файла при инклуде. 3) Во инклудящемся файле объявляется наш массив StaticClass::$Data = Array(/*лалалалалалалала*/); 4)... 5) PROFIT! При инклуде данные автоматом заносятся куда надо.
Код (Text): class Test { public static function init() { // всякое тут } } Test::init(); При инклуде этого файла исполнится и метод. Добавлено спустя 1 минуту 9 секунд: Ну если у тебя объект существует одна штука на запрос, то можно и не делать объект, а обойтись статикой в классе. Например, подключение к бд.
Я невнимательно читал или __construct() сейчас не в моде (в листинге тса увидел объект, стало быть он есть)?
тебе надо осмыслить инкапсуляцию. Она нужна, чтобы разные экземпляры не мешать друг с другом. Т.е. вопрос лишён смысла. Оно тебе либо нужно, и тогда только экземпляры, либо не нужно и тогда пофик как.
беда заключается в том что я еще толком сам не знаю, нужна ли тут эта капсюляция, объекты короче, класс будет обслуживать шаблон (HTML, подключение файлов и т.д. в том числе будут в свойствах класса храниться данные - имена файлов, пути и т.д.) и по хорошему, шаблон всегда один, по этому ни какие объекты не нужны, а с другой стороны вдруг понадобиться Я так размышлял и пришел к тому, что самый идеальный вариант это будет использовать не статические методы, как статические, даже схему продумал, получается я мог создавать объекты и использовать как статику, но сначала меня один товарищ напугал ошибками (предупреждениями), я затестил, предупреждений не было, потом я зашел в эту тему - viewtopic.php?t=52536 скопировал ini_set и выяснилось что ошибка то есть (предупреждения). Добавлено спустя 3 минуты 57 секунд: невнимательно, речь идет о статических методах, а у статики нет конструктора.
Инкапсуляция. VLK, а может тебе тупо на функциях писать, не? Не вариант? Зачем ООП тулить туда, где оно тебе не нужно?
Кроме чувства моды и илитности от ООП-ради-ООП-даже-там-где-оно-не-нужно-и-порождает-костыли-иначе-бы-ты-не-создал-этот-тред, в чем еще проявляется устаревание? Я миллион раз говорил, и повторю миллион раз первый - ООП не лучше функций, функции не лучше ООП, это два разных подхода. ООП это не "новая волна и мода", это инструмент. И функции - инструмент. Если для забивания гвоздя нужен молоток, возьми милоток, не морочься с паяльником. Особенно учитывая то, что в PHP обе парадигмы легко гибридизируются.