Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Никто не совершенен. Объектная модель PHP тоже. Но язык силен не этим. Так что не стоит его забрасывать помидорами. Везде есть мелкие недостатки.
Именно, что ООП в PHP - это не основная сущеность, а бонус, расширение языка.
Проблема далеко не в объектной модели языка.
К сожалению это тенденция в языке - в нем полно таких мелочей, которые не заставляют тебя бросить все, но настроение порой портят.
Да и главное преимущество языка - его простота, но это палка о двух концах ;)
Да и главное преимущество языка - его простота, но это палка о двух концах ;)
а чем он силен?
В проблеме автора топика повинен не PHP, а его собственное извращенное понимание ООП (статических функций и наследования) и паттернов проектирования. Будет благом, если в PHP 6 разработчики не позволят так издеваться над языком и принципами ООП.
Автору можно порекомендовать читать книжку Гради Буча "Объектно-ориентированный анализ и проектирование" до просветления.
Автору можно порекомендовать читать книжку Гради Буча "Объектно-ориентированный анализ и проектирование" до просветления.
А можно ли поконструктивнее? Я бы с удовольствием посмотрел как это реализуется правильно в соответствии с канонами ООП.
А раннее статическое связывание self-а это ИМХО зло, поскольку ведет себя отнюдь не так, как того ожидает программист.
А раннее статическое связывание self-а это ИМХО зло, поскольку ведет себя отнюдь не так, как того ожидает программист.
Не думаю, что возможно обучить ООП в комментариях к топику.
Ниже вам советуют приемлемое (не идеальное) решение — фабрика, которая будет управлять созданием и доступом к нужным объектам.
И вообще, каждый раз, когда возникает желание использовать "одиночку", необходимо крепко задуматься, так ли это нужно.
Вот для каких лбъектов это необходимо?
Ниже вам советуют приемлемое (не идеальное) решение — фабрика, которая будет управлять созданием и доступом к нужным объектам.
И вообще, каждый раз, когда возникает желание использовать "одиночку", необходимо крепко задуматься, так ли это нужно.
Вот для каких лбъектов это необходимо?
то что программсист ожидает от языка поведения, прямо противоположного документации - личные проблемы программиста.
было бы неплохо почитать, что бы вы сделали в этом случае согласно бучу
Для начала нужно узнать зачем авторувот это понадобилось: "Задача стояла довольно обыкновенная - нужно было использовать паттерн Singleton для некоторого количества классов".
Тут принципиально не важно какова задача, необходим ли тут паттерн Одиночка вопрос не стоит. Стоит вопрос как его просто и красиво реализовать на PHP.
проблема в том, что вы сначала придумываете что там будет такой паттерн, там сякой и пытаетесь _это_ как-то автоматизировать в рамках ПХП. Это паттерны _проектирования_. Не прогарммирования, а проектирования.
Да, иногда в языке есть средства для удобной реализации запроектированных на паттернах решений, иногда их можно создать средствами языка. Но вот лично мне за шесть лет коммерческого прграммирования ситуации, где такие низкоуровневые по ООП-понятиям вещи надо было реализовывать "в общем виде" встречались ой-как редко.
За очевидным, опять-же, исключением тех случаев, когда язык позволяет это сделать легко и естественно.
Да, иногда в языке есть средства для удобной реализации запроектированных на паттернах решений, иногда их можно создать средствами языка. Но вот лично мне за шесть лет коммерческого прграммирования ситуации, где такие низкоуровневые по ООП-понятиям вещи надо было реализовывать "в общем виде" встречались ой-как редко.
За очевидным, опять-же, исключением тех случаев, когда язык позволяет это сделать легко и естественно.
Добавлю к посту Caesar'а:
Если на этапе проектирования задуматься — а все и верно в структуре классов/объектов, если к каким-то из них появляется необходимость в глобальном доступе из любой точки программы (singleton, ага) — проблем сильно поубавится.
Ничего сложнее вот такого кода не нужно (ищем 10 отличий от реализации из топика):
Если на этапе проектирования задуматься — а все и верно в структуре классов/объектов, если к каким-то из них появляется необходимость в глобальном доступе из любой точки программы (singleton, ага) — проблем сильно поубавится.
Ничего сложнее вот такого кода не нужно (ищем 10 отличий от реализации из топика):
final class Foo
{
private static $instance ;
private function __construct() {}
private function __clone() {}
public static function getInstance()
{
return(null == self :: $instance ? self :: $instance = new self() : self :: $instance) ;
}
}
10 отличий не найдено. Проблемы возникают когда мне нужно 10 таких классов, писать это 10 раз мне лень, а вам?
Про фабрики не будем, уже говорилось.
Про фабрики не будем, уже говорилось.
> Проблемы возникают когда мне нужно 10 таких классов
Ну вот, сами себе и ответили.
Вам не нужно 10 таких классов никогда. Если архитектура приложения требует этого и это вызывает проблемы — так это плохая архитектура, при чем тут язык?
До сих пор вы смогли из себя извлечь только пример с "объектом подключения к базе данных". Конкретная реализация работы с БД в приложении — опять же вопрос архитектуры приложения, причем, заметим, вопрос открытый. Никто насильно использовать в реализации синглтоны не заставляет. А уж если инфантильно заявили "Хочу!" и использовали, смешно потом жаловаться на язык, ищите проблемы в своей кривой архитектуре.
Ах да, с нетерпением жду в вашем следующем сообщении примеры еще 9 насущных и незаменимых применений синглтона, помимо "объекта подключения к базе данных".
Ну вот, сами себе и ответили.
Вам не нужно 10 таких классов никогда. Если архитектура приложения требует этого и это вызывает проблемы — так это плохая архитектура, при чем тут язык?
До сих пор вы смогли из себя извлечь только пример с "объектом подключения к базе данных". Конкретная реализация работы с БД в приложении — опять же вопрос архитектуры приложения, причем, заметим, вопрос открытый. Никто насильно использовать в реализации синглтоны не заставляет. А уж если инфантильно заявили "Хочу!" и использовали, смешно потом жаловаться на язык, ищите проблемы в своей кривой архитектуре.
Ах да, с нетерпением жду в вашем следующем сообщении примеры еще 9 насущных и незаменимых применений синглтона, помимо "объекта подключения к базе данных".
Ну если вам так уж интересно я вам отвечу — мне пришлось реализовывать обьекты, описывающие модели данных через синглтоны, поскольку, опять же, я не мог сделать это просто статическими методами класса из-за раннего связывания модификатора
Кроме того я не хотел, чтобы некоторые процедуры инициализации выполнялись каждый раз, как возникает нужда в этом объекте.
Что же касается ваших сомнений в моем профессионализме, то мне кажется они необоснованы. Конечно я решил свои задачи иным способом, но этот способ, работай он как в "нормальных" (читайте "поддерживающих общепринятые модели") языках, был бы гораздо удобнее в понимании и поддержке.
И позвольте мы не будем спорить о целесообразности этого подхода. В конце-концов это не есть тема этой статьи.
self. И это по одному классу на практически каждую таблицу данных, и сделать их одним классом нельзя, поскольку они имеют собственные методы.Кроме того я не хотел, чтобы некоторые процедуры инициализации выполнялись каждый раз, как возникает нужда в этом объекте.
Что же касается ваших сомнений в моем профессионализме, то мне кажется они необоснованы. Конечно я решил свои задачи иным способом, но этот способ, работай он как в "нормальных" (читайте "поддерживающих общепринятые модели") языках, был бы гораздо удобнее в понимании и поддержке.
И позвольте мы не будем спорить о целесообразности этого подхода. В конце-концов это не есть тема этой статьи.
Если сравнивать ущербную реализацию классов в ПХП с "полновесной" реализацией в "полновесных" языках - сразу становиться понятно что классы в ПХП не ушербны. А просто другие.
Да - лишонные части ТРЕБУЕМОГО "большими красивыми книжками" функционала ( например ну нельзя определить виртуал или оверайд и так далее, ну просто нельзя)
В то же время имеюшие свой дополнительный пхпшный(и на мой взгляд очень удобный) функционал..
Как реализуется синглентон "по александреску"?
добавление статического темплейтного мембера. Тоесть фактические - синглентон база хоть и называется синглетоном - для компилятора софсем другой класс( раз параметры темплейта другие)..
Как реализуется синглентон на пхп?
Лично у меня просто - DataBase(), CurrentUser(), Log() и тд.
Функции фабрики.
Это просто(тело функции - две(три) строчки)
Это удобно.
Это работает.
Не думаю что следует переносить технологии кодинда "полновесных" языков на энтепритируемый пхп.
По мне так - ему это не надо :)
Да - лишонные части ТРЕБУЕМОГО "большими красивыми книжками" функционала ( например ну нельзя определить виртуал или оверайд и так далее, ну просто нельзя)
В то же время имеюшие свой дополнительный пхпшный(и на мой взгляд очень удобный) функционал..
Как реализуется синглентон "по александреску"?
добавление статического темплейтного мембера. Тоесть фактические - синглентон база хоть и называется синглетоном - для компилятора софсем другой класс( раз параметры темплейта другие)..
Как реализуется синглентон на пхп?
Лично у меня просто - DataBase(), CurrentUser(), Log() и тд.
Функции фабрики.
Это просто(тело функции - две(три) строчки)
Это удобно.
Это работает.
Не думаю что следует переносить технологии кодинда "полновесных" языков на энтепритируемый пхп.
По мне так - ему это не надо :)
Сделайте синлтон-регистр
self::$instance = new self();
->
$class = get_class();
self::$instance = new $class;
->
$class = get_class();
self::$instance = new $class;
Не нужно предлагать костыли.
если get_class() вызывается в статическом методе, он не вернет имя наследника. Костыль, который обсуждается на http://www.php.net/get_class можно сделать только через debug_backtrace(), но это уже будет мегакостыль
К вышесказанному добавлю, что self::$instance для зывоса из разных дочерних классов все равно будет хранить один объект на всех.
Не могу понять причем здесь PHP? Статические поля - переменные класса.
Заголовок "Почему я не люблю PHP"
Вы не любите php потомучто нашли в нем один баг ? Как вам тогда вообще живется ? Во всех программах и операционках (дада, не только от микрософта но и от эппл и от линукс) - есть баги. Давайте создадим топики Почему я не люблю OS Windows, Почему я не люблю Mac, почему я не люблю фотошоп/ворд/quake/... - и опишем по одному багу!
Вы не любите php потомучто нашли в нем один баг ? Как вам тогда вообще живется ? Во всех программах и операционках (дада, не только от микрософта но и от эппл и от линукс) - есть баги. Давайте создадим топики Почему я не люблю OS Windows, Почему я не люблю Mac, почему я не люблю фотошоп/ворд/quake/... - и опишем по одному багу!
Во-первых это не баг, это фича :)
В документации все описано, просто могли бы (и сделали в новой версии) и удобнее.
А PHP я не люблю за то, что там таких фич на каждом шагу, в общем все работает, но настроение портит.
Я из тех наивных программистов, которые считают что красота кода способна приносить удовольствие, так вот PHP частенько ломает весь кайф ;)
Это мысль из серии "Вот за такие неприятные мелочи я его и не люблю".
В документации все описано, просто могли бы (и сделали в новой версии) и удобнее.
А PHP я не люблю за то, что там таких фич на каждом шагу, в общем все работает, но настроение портит.
Я из тех наивных программистов, которые считают что красота кода способна приносить удовольствие, так вот PHP частенько ломает весь кайф ;)
Это мысль из серии "Вот за такие неприятные мелочи я его и не люблю".
> PHP я не люблю за то, что там таких фич на каждом шагу
Не знаю, сколько у вас "шагов", но список из 10—20 таких "фич" будет достаточен. А потом можно будет обсудить, сколько из них вызывают неудобства у подавляющего большинства разработчиков, а сколько — конкретно у вас, с вашим альтернативным пониманием их.
Не знаю, сколько у вас "шагов", но список из 10—20 таких "фич" будет достаточен. А потом можно будет обсудить, сколько из них вызывают неудобства у подавляющего большинства разработчиков, а сколько — конкретно у вас, с вашим альтернативным пониманием их.
Не привязывайтесь к заголовку просто, он же тут нужен исключительно для привлечения внимания. Смотрите на мир шире :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я не люблю PHP