-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Когда уже наконец выйдет PHP5.3 ?
- Автор темы cDLEON
- Дата начала
- Статус
x-yuri
Новичок
а почему с абстрактными классами легче рефакторить, чем с интерфейсами?
-~{}~ 10.01.09 22:09:
и зачем ты в конструктор вынес "создание" объекта? это экономия одной строчки в каждом потомке? то же самое по поводу $instance в классе singleton?
-~{}~ 10.01.09 22:15:
и кроме того ты собираешься наследоваться от test и переопределять там get_instance?
-~{}~ 10.01.09 22:09:
и зачем ты в конструктор вынес "создание" объекта? это экономия одной строчки в каждом потомке? то же самое по поводу $instance в классе singleton?
-~{}~ 10.01.09 22:15:
и кроме того ты собираешься наследоваться от test и переопределять там get_instance?
cDLEON
приведи хоть один реальный пример c живой логикой, где использование потомка синглтона может иметь хоть какой-то смысл
(смайлик со слезами)
-~{}~ 11.01.09 03:01:
предвижу вариант ответа: "разные классы для работы с разными БД, расширяющие единый родительский синглтон",
на что будет мсй вопрос "а юнит-тесты и работа с 2мя БД?" и ответ, сводящийся к "у меня 2х баз не было, а что такое юнит-тесты?"
приведи хоть один реальный пример c живой логикой, где использование потомка синглтона может иметь хоть какой-то смысл
(смайлик со слезами)
-~{}~ 11.01.09 03:01:
предвижу вариант ответа: "разные классы для работы с разными БД, расширяющие единый родительский синглтон",
на что будет мсй вопрос "а юнит-тесты и работа с 2мя БД?" и ответ, сводящийся к "у меня 2х баз не было, а что такое юнит-тесты?"
cDLEON
Онанист РНРСlub
grigori
Ну что то вроде этого 8))
А теперь - рыдай
ЗЫ. Вообще я уже отказался от этих паттернов вообще. Очень не предсказуемый код потом получается 8) Хрен поймёшь кто и где вызывает 8) Да и вообще, мне кажется, что этими паттернами прикрывают плохую архитектуру... Собственно мнение сформировалось после года использования оных... Теперь мой быдло-фреймворк заманаешься рефакторить )
PHP:
abstract class router extends singleton {
protected $args;
protected $root;
protected $req_file_name;
abstract static function get_args();
abstract static function get_root();
abstract static function get_req_file_name();
}
class router_command_line extends router {
}
class router_web_rewrite extends router {
}А теперь - рыдай
ЗЫ. Вообще я уже отказался от этих паттернов вообще. Очень не предсказуемый код потом получается 8) Хрен поймёшь кто и где вызывает 8) Да и вообще, мне кажется, что этими паттернами прикрывают плохую архитектуру... Собственно мнение сформировалось после года использования оных... Теперь мой быдло-фреймворк заманаешься рефакторить )
cDLEON, ну тогда все понятно - проблема в паттернах!
вот перепишешь паттерны - и заживешь!
(вот мы тут на Украине тоже думаем: если в 17м году Россия таки выведет флот из Крыма, у наших националистов пропадет смысл жизни ... что делать?!)
По сути: "ты рыбу ловишь? нет, я рыбу ловлю".
Как я и предполагал, ответ - расширение "служебного" класса разными реализациями для взаимодействия с разными однородными внешними средами с целью приведения объектов к схожему API.
Для этой цели существует понятие "интерфейс"
А твой быдло-фреймверк заманаешься не только рефакторить, но и читать, и тестировать, и использовать где-либо, кроме того проекта, для которого ты "фреймворк" написал
Тут я с тобой согласен, поможет только одно: забить на паттерны с ООП, писать функциональный код.
вот перепишешь паттерны - и заживешь!
(вот мы тут на Украине тоже думаем: если в 17м году Россия таки выведет флот из Крыма, у наших националистов пропадет смысл жизни ... что делать?!)
По сути: "ты рыбу ловишь? нет, я рыбу ловлю".
Как я и предполагал, ответ - расширение "служебного" класса разными реализациями для взаимодействия с разными однородными внешними средами с целью приведения объектов к схожему API.
Для этой цели существует понятие "интерфейс"
А твой быдло-фреймверк заманаешься не только рефакторить, но и читать, и тестировать, и использовать где-либо, кроме того проекта, для которого ты "фреймворк" написал
Тут я с тобой согласен, поможет только одно: забить на паттерны с ООП, писать функциональный код.
cDLEON
Онанист РНРСlub
Можешь наставить меня на путь истинный? В каком месте у меня промах? В том, что пытаюсь сделать код, для которого не нужны будут "адапторы"? А наследованием я хочу убрать копи-паст?
И вообще - чем плохо вместо интерфейсов использывать абстрактные классы? В чём их минус?
Я не волшебник, я только учусь 8)
А по поводу политики - я вообще не знаю о чём вы думаете там, сливая миллиарды на очередные перевыборы.
А вот здесь по-подробнее. Как написать так, что бы всё, что ты перечислил делать без проблем? ) Использывать интерфейсы? Ты к этому ведёшь?)))
-~{}~ 13.01.09 03:08:
Мысли вслух...
Вот скачал я себе два разрекламированных фреймворка...
Окей думаю. Клёво. Заценю скорость. Скачал два "скелета" веб-приложений. В одном и во втором ни чего кроме вывода статического шаблона welcome нет. В итоге и первый и второй фреймворк выполнялся примерно 0.3 сек. Для сравнения - мой быдло-фреймворк выполнял ту же задачу за 0.03-0.09 секунды на этой же машине, и имел примерно такое же апи, для решения этой задачи.
Сразу же оговорюсь - я не ставлю в пример его. Потому как действительно дело с рефакторингом своего кода внутри "фреймворка" у меня чаще всего заканчивается мусорной корзиной...Вот, собственно, и пытаюсь узнать "секрет успеха". Который мне не удалось накопить за 3 года самообучения...
x-yuri
Новичок
промах в том, что ты наследованием хочешь убрать копи-паст, оно не для того предназначено
код лучше писать для человека, а не для компьютера. А уже _потом_ смотреть что именно тормозит, как это улучшить и какой выигрыш в скорости ты получишь. И если это действительно важно для твоей конкретной задачи, то тогда стоит оптимизировать
Первое что приводят неудачники в своих фреймворках это скорость.
Давай потягаемся с Xcache чтоб кешировался код которого у меня явно больше ?)
А главное что ты берешь 1 частичку маленкую отдельно написанную и такуюже частичку из огромной кучи. Конечно твоя будет быстрее, но если затронуть все вместе то тут как обычно у горе фреймворков начинаются проблемы))
Давай потягаемся с Xcache чтоб кешировался код которого у меня явно больше
?)А главное что ты берешь 1 частичку маленкую отдельно написанную и такуюже частичку из огромной кучи. Конечно твоя будет быстрее, но если затронуть все вместе то тут как обычно у горе фреймворков начинаются проблемы))
cDLEON
Онанист РНРСlub
Первое, что пишут неудачники у себя в инфе, это слово "хххххх".
А уже потом приводят оправдание в виде скорости.
Я с быдлом писюнами не меряюсь.
Кстати - если для вывода простейшей статичной странички у тебя подгружается весь фреймворк полностью - то те слова у тебя в инфе - правда.
Но я ведь не только копи-паст убираю ))) Вообще наследованием я стараюсь решить однотипные задачи для всех потомков) Как бы стандартизировать их...
Виндой здесь попахивает, батенька, виндой ))
А вообще - я с тобой согласен - но когда 0.3 сек выполняется вывод какой то задрыпанной странички - по мне - черезчур..
Всё должно быть в меру...
-~{}~ 13.01.09 03:32:
Нет, я беру целый фреймворк. Свой и чужой - с, подчёркиваю, практически одинаковым, предоставляемым апи, для решения этой задачи - вывода куска статического шаблона.
x-yuri
Новичок
В том то и дело. Наследование нужно для того, чтобы определить общий _интерфейс_, через который будет осуществляться работа с потомками
Виндой говоришь? http://en.wikipedia.org/wiki/Unix_philosophy#Raymond:_The_Art_of_Unix_Programming (Rule of Economy)
и это еще стоит вспомнить: "Premature optimization is the root of all evil." (с) Donald Knuth
так ты сделай сайт на этом фреймворке. Посмотри, что именно в нем тормозит, сделай выводы и напиши фреймворк лучше.
Ты ж говоришь, что у тебя проблемы с рефакторингом? Ну и к чему тебе твоя скорость если твой проект с трудом поддается изменениям?
cDLEON
Давай ка ты будешь полегче на поворотах, акей?
Одинковое API можно реализовать множеством способов. Например можно в тупую вывести, а можно проверить права пользователя и т. д.
Есть еще многое что подружаеться и выводиться не явно, адаптеры, хуки, ацл и т. д. и это все представляешь?! для вывода одной статичной страницы о ужас. И тут являешься ты под звуки небесных арф с фреймворком
class Framework
{
function showPage( $source )
{
include $source;
}
}
И тупо всех в кизяки по скорости!!!!!
Давай ка ты будешь полегче на поворотах, акей?
Одинковое API можно реализовать множеством способов. Например можно в тупую вывести, а можно проверить права пользователя и т. д.
Ога, конечно. А ты у нас умничка. Чмафки тебя фпузо.
Есть еще многое что подружаеться и выводиться не явно, адаптеры, хуки, ацл и т. д. и это все представляешь?! для вывода одной статичной страницы о ужас. И тут являешься ты под звуки небесных арф с фреймворком
class Framework
{
function showPage( $source )
{
include $source;
}
}
И тупо всех в кизяки по скорости!!!!!
- Статус