-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
ООП : опрос + флуд
- Автор темы betik
- Дата начала
lovchy
nacido para cifrar
ONK
Пустой трёп. Есть паттерн синглтон. Он решит все твои проблемы. Прежде чем начинать говорить про скорость -- протестируй. Полагаю, результаты тебя очень удивят. Если скажешь, что небольшая разница всё же есть, сразу будешь отправлен писать расширения на C. Задолбал аэрофлот: PHP язык _высокого_ уровня. Глупо требовать от него чудес производительности. Не мне тебе объяснять, что наносекунды, о которых может идти речь, никогда не потребуется исключать.
Что касается $_SERVER и всего остального: просто воспринимай $_SERVER[] как функцию get_server_var.
Ещё аргументы про глобальные переменные?
Пустой трёп. Есть паттерн синглтон. Он решит все твои проблемы. Прежде чем начинать говорить про скорость -- протестируй. Полагаю, результаты тебя очень удивят. Если скажешь, что небольшая разница всё же есть, сразу будешь отправлен писать расширения на C. Задолбал аэрофлот: PHP язык _высокого_ уровня. Глупо требовать от него чудес производительности. Не мне тебе объяснять, что наносекунды, о которых может идти речь, никогда не потребуется исключать.
Что касается $_SERVER и всего остального: просто воспринимай $_SERVER[] как функцию get_server_var.
Ещё аргументы про глобальные переменные?
Crazy
Developer
Доктор, попробуй перестать юродствовать. Это может помочь.
Аргументы:
1. Глобальную переменную кто-то должен иницилизировать. И код инициализации получается полностью оторван от места использования, что затрудняет отслеживение ошибок. Доступ через функции не имеет этого недостатка.
2. При работе с глобальное переменной операции над ней неконтролмируемы. Типичная проблема -- реинициализация. Доступ через функции не имеет этого недостатка.
Обращаю внимание: не прозвучало ни одного здравого аргумента ЗА использование глобальных переменных (если не брать откровенно смешные рассуждения о скриптах, у которых чтения конфига занимает 90% времени работы).
Но, как я уже отмечал, сторонники использования глобальных переменных УЖЕ знают, что они абсолютно правы и не тратят времени на чтение чужих аргументов...
jendos
Guest
II.
Органичения чисто в реализации.
Не использую ООП для выполнения простейших преобразованиий экземпляра класса, если класс слишком подробно описан(большое количество методов и т.п.) а необходимо использовать всего лишь малую часть для работы над объектом(например всего лишь один метод) то однозначно простейшая реализация без ООП.
Чем "навороченнее" класс, тем существеннее замедляется работа скрипта, так как тратиться дополнительное время на создание экземпляра класса.
Органичения чисто в реализации.
Не использую ООП для выполнения простейших преобразованиий экземпляра класса, если класс слишком подробно описан(большое количество методов и т.п.) а необходимо использовать всего лишь малую часть для работы над объектом(например всего лишь один метод) то однозначно простейшая реализация без ООП.
Чем "навороченнее" класс, тем существеннее замедляется работа скрипта, так как тратиться дополнительное время на создание экземпляра класса.
jendos
Guest
С этим не спорю, но всё -таки не улавливаю разницу для скорости работы между
описанием объекта группой классов и описанием объекта одним классом. Объект как экземпляр класса(группы классов)
- один. Соответственно, если говорить о PHP , то при создании экземпляра инициализируются все методы без исключения, пусть даже если она разбиты на группы.
jendos
Guest
а если у меня один объект к которому надо применить кучу методов . Так не АгА?
А вообще-то в PHP - при создании экземпляра инициализируются ВСЕ методы того класса к которому ЭТОТ экземпляр принадлежит.
Прошу не путать инициализацию метода с его с применением к объекту в контексте одного скрипта
А вообще-то в PHP - при создании экземпляра инициализируются ВСЕ методы того класса к которому ЭТОТ экземпляр принадлежит.
Прошу не путать инициализацию метода с его с применением к объекту в контексте одного скрипта
jendos
Guest
извиняюсь за неточность. В действительности нужно использовать один метод.
Фаулера в *.chm почитал бы. Учиться не грешно )).
2Crazy
Ваша логика понятна: "пусть каждый отвечает сам за свою работу и работает только тогда, когда это от него требуется" - если я вас правильно понял.
Я немного с другой позиции рассуждаю.
Фаулера в *.chm почитал бы. Учиться не грешно )).
2Crazy
Ваша логика понятна: "пусть каждый отвечает сам за свою работу и работает только тогда, когда это от него требуется" - если я вас правильно понял.
Я немного с другой позиции рассуждаю.
lovchy
nacido para cifrar
ONK
Пассивист PHPСluba
jendos, при создании объекта класса не происходит никакой инициализации методов, это полный бред.
Методы класса "инициализируются" на этапе парсировки ПХП кода, при создании объекта ему передаётся ссылка на хэш-таблицу с опкодом методов класса.
Все накладные расходы при создании объекта класса связаны только с вызовом конструктора и операциями в нём.
Другое дело, что общепринятый способ доступа к данным класса через методы типа get_ххх(...), из-за дорогой стоимости вызова функции в ПХП, является достаточно медленным ( ~ 15 раз медленнее прямого доступа), что (как я ранее писал) при множественном использовании в длинных циклах, в реальных приложениях приводит к 2 - х ... 3 - х кратному замедлению работы скрипта.
Я не хотел отвечать на странные выпады Crazy, по моему, он ведёт себя не адекватно,
но пожалуй прокомментирую их:
Попытки донести до общественности, что глобальные переменные сплошной вред я считаю неразумными, о чём и пытался сказать своими сообщениями. Глобальные переменные ПХП это полезное средство языка, которым надо уметь грамотно пользоваться. Замечу что в ПХП работа с глобальные переменными построена значительно лучше (безопаснее) чем в С С++. Испортить из в нормально спроектированном приложении (в котором просто нет прикладного кода выполняющегося в глобальном пространстве имён) подобные переменные не так просто. Попытки обходиться вообще без глобальных переменных это ограничение своих возможностей и снижение эффективности кода. На странные предложения считать суперглобальные массивы функциями, могу предложить считать все глобальные переменные, переменными полученными с помощью "синглтон паттерна".
При всём при этом, создание глобальных переменных из прикладного кода я считаю не допустимым (правда я ниразу не сталкивался с такой необходимостью)
Методы класса "инициализируются" на этапе парсировки ПХП кода, при создании объекта ему передаётся ссылка на хэш-таблицу с опкодом методов класса.
Все накладные расходы при создании объекта класса связаны только с вызовом конструктора и операциями в нём.
Другое дело, что общепринятый способ доступа к данным класса через методы типа get_ххх(...), из-за дорогой стоимости вызова функции в ПХП, является достаточно медленным ( ~ 15 раз медленнее прямого доступа), что (как я ранее писал) при множественном использовании в длинных циклах, в реальных приложениях приводит к 2 - х ... 3 - х кратному замедлению работы скрипта.
Я не хотел отвечать на странные выпады Crazy, по моему, он ведёт себя не адекватно,
но пожалуй прокомментирую их:Мне непонятно откуда могла взяться подобная оценка, скорее я мог бы выдвигать такие "обвинения", но мне понятно, что ты просто пытаешься интерпретировать всё сказанное мною наиболее удобным тебе способом.
замечательный пример вышесказанного мною. Всё ранее написанное мною отвергается как несостоятельное, и непонятно откуда появляются странные домыслы.
Выше ты привёл код функции get_config() из которого совершенно очевидно, что заявление:
Ошибочно, т.к. переменная передаётся по ссылке. Единственный способ избежать записи мусора, или реинициализации переменной, это передавать её по значению, что в большинстве случаев недопустимо расточительно.
Как я писал ранее, глобальные переменные, необходимые для работы системы могут инициализироваться / модифицироваться только средствами API системы. Таким образом места их инициализации / модификации строго определены и известны. Так что значение этого довод сильно приувеличено.
Попытки донести до общественности, что глобальные переменные сплошной вред я считаю неразумными, о чём и пытался сказать своими сообщениями. Глобальные переменные ПХП это полезное средство языка, которым надо уметь грамотно пользоваться. Замечу что в ПХП работа с глобальные переменными построена значительно лучше (безопаснее) чем в С С++. Испортить из в нормально спроектированном приложении (в котором просто нет прикладного кода выполняющегося в глобальном пространстве имён) подобные переменные не так просто. Попытки обходиться вообще без глобальных переменных это ограничение своих возможностей и снижение эффективности кода. На странные предложения считать суперглобальные массивы функциями, могу предложить считать все глобальные переменные, переменными полученными с помощью "синглтон паттерна".
При всём при этом, создание глобальных переменных из прикладного кода я считаю не допустимым (правда я ниразу не сталкивался с такой необходимостью)
lovchy
nacido para cifrar
ONK
Кому? Известны тебе, не известны другим. К тому же, если можно программно запретить себе сделать ошибку, -- лучше запретить, а не пологаться на свою память и свой интеллект. Слишком часто они людей подводят.
Неимоверно полезны также переменные переменные и eval. Угу.
Либо незнание эффективных альтернативных способов. Если ты не видишь решений -- это ещё не значит, что их нет.
Синглтон не даёт возможности переписать. Это очень немаловажно. Читай выше.
Индюк тоже думал. А людям свойственно ошибаться (опечатки, недосмотры, ...). Почему бы не предусмотреть всё это программно?