Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
Друзья, я конечно все понимаю. Но накой такой сложный Singleton? О задаче этого паттерна ни кто не забыл? Запретить случайное создание более одного объекта! А на вашем Singleton'е в космос можно улететь. Я понимаю что этот Singleton мега крут, но помоему занудство и излишество. До сути (что будет решать уже конкретный класс) в этих дебрях не добраться.
Все эти 100500 вызовов функций, сериализация параметров (где вообще гарантия, что они сериализуются?), запись в глобалсы — академически правильный код?
Первоочередной принцип программирования: не засорять пространство видимости имен в том числе и глобальное. В данном случае этот принцип соблюдается. Запись в глобасы… Вы уж простите, даже формулируется не академически.
Вас не смущает md5 и serialize в getInstance? У меня почему-то какое-то странное давящее ощущение в животе, что это неправильно, и надо делать обычный реестр и конфиг с обычными ключами вроде 'shard_1' и 'shard_2' вместо вычисления контрольных сумм (которая, к слову, имеет потенциальные коллизии). И ещё вроде, класс должен называться CMyDb, а не MyCDb, если уж следовать венгерской нотации. Хотя зачем ей следовать только в именах классов, тоже не понятно.
К сожалению или к счастью, как показывает практика, академическому коду почти нет места в реальных проектах
В общем никто не запрещает использовать его как обычный синглетон. В моей практике был такой случай, когда разработчикам понадобился еще один интерфейс подключения к ведомой СУБД. Решение потрясало своей простотой и «изящностью»: был создан класс DB2 — копия DB только с необходимыми настройками,
Это не академический подход, как некоторые тут говорят, но зато в реальном проекте.
Это не академический подход, как некоторые тут говорят, но зато в реальном проекте.
Есть мнение, что делать класс DB синглтоном плохая практика. В данном случае вы реализуете и код, отвечающий за работу, и код, отвечающий за инициализацию (конфиги, ресурсы) в одном месте, что не есть хорошо. Из-за этого, как минимум, страдает переносимость кода. Если у вас появятся две базы данных, вам придется создать два класса, наследующих один абстрактный класс, вместо того, что бы проинициализировать один класс два раза с разными параметрами. Not good.
«изящностью» в кавычках. Верно.
«изящностью» в кавычках. Верно.
Смотря с какой точки зрения на это смотреть. Я сторонник слабо-связанной архитектуры. В таком случае наш класс Db сам по себе и не зависит ни от кого в создании и конфигурации.
В крайнем случае можно использовать MessageBus как связующий компонент для конфигурации отдельных компонентов.
И если у меня появятся две новые базы я просто изменю базовый класс.
В крайнем случае можно использовать MessageBus как связующий компонент для конфигурации отдельных компонентов.
И если у меня появятся две новые базы я просто изменю базовый класс.
Есть мнение, что не стоит делать из пыхапе еще одну джаву. Это конечно здорово, что такое вообще стало возможно, но…
Они как бы для разных вещей предназначены. Если нужна джава, надо просто взять джаву, с томкатом и гибернацией.
Они как бы для разных вещей предназначены. Если нужна джава, надо просто взять джаву, с томкатом и гибернацией.
Тем более, что на джаве такого не сделать :).
А что, копипаст в джаве забанили? :)
Ну вроде как в следующей версии будут и в джаве миксины.
Ну вроде как в следующей версии будут и в джаве миксины.
И особо никто на восьмой версии не попишет. Все-таки шестая джава крепко засела как стандарт де-факто джава-кодинга. Практически все популярные библиотеки написаны на шестой версии (некоторые даже совместимы с пятой), opensource-реализации джавы тоже еще не совместимы с семеркой. Мир php как-то быстрее подтягивается за новшествами языка.
ЗЫ: Имел ввиду, что джава попроще будет, нежели php последних версий, в плане вариативности синтаксических конструкций :).
ЗЫ: Имел ввиду, что джава попроще будет, нежели php последних версий, в плане вариативности синтаксических конструкций :).
зачем это в джаве? Скала же есть, там и миксины, и синглтоны на уровне языка.
Реализуйте метод getInstance и не выносите людям мозг.
Дебют, у автора, явно, не удался. Первый пост — комом.
Что я могу сказать, почитайте о Бритве Оккама.
Вот сейчас придет сюда EugeneOZ и подробнейшим образом объяснит, чем плох синглтон и что надо сделать с программистом, который его использует :)
боже что за бред.
патерн Registry? нееее, не слышали…
патерн Registry? нееее, не слышали…
Шел 2012 год, пехепе-программисты все еще реализовывали синглтон…
Помню, ещё два года назад, когда я был зеленым юнцом, это был мой любимый паттерн и реализовал я его за две минуты в 10 строках кода.
Любой паттерн — это решение проблемы, поставленной задачи и каждый это решение видит по-своему.
Скажите а для каких задач этот космос нужен? Какие реальные преимущества перед обычным синглтоном?
Под обычным (для php) я понимаю:
class ExampleClass {
protected static $instance;
public static function getInstance(){
if(is_null(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
}
Ну и при встрече «global» в коде, вне зависимости от обстоятельств, мне почему-то хочется убивать.
Под обычным (для php) я понимаю:
class ExampleClass {
protected static $instance;
public static function getInstance(){
if(is_null(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
}
Ну и при встрече «global» в коде, вне зависимости от обстоятельств, мне почему-то хочется убивать.
Основные особенности паттерна я отметил в самом начале статьи. Где это можно применить — каждый пусть решает сам.
Я видел особенности, поэтому и спросил о реальных применениях. Я считаю, что эти особенности противоречат самой сути синглтона. Одиночка на то и одиночка, для него не нужно никаких настроек при создании объекта, он не может существовать в приложении в разных экземлярах, отсюда и наследование от него смысла не имеет. Для решения этих задач лучше фабрика и/или реестр. Сингтон он независимый, он один и тот же на протяжении всего сценария, максимум он может зависеть от запроса или каких-то глобальных вещей, и то этого стоит избегать. Параметрический синглтон — ну это же фабрика, только ограниченная и запутанная. Зачем так странно смешивать паттерны?
По global: где гарантии что кто-то в будущем не захочет переопределить (случайно или специально) эти global значения и на проекте начнется ад.
Ну это мое мнение.
По global: где гарантии что кто-то в будущем не захочет переопределить (случайно или специально) эти global значения и на проекте начнется ад.
Ну это мое мнение.
phpgoodness.wordpress.com/2010/07/21/singleton-and-multiton-with-a-different-approach/
Другие люди так не считают.
Другие люди так не считают.
Ну там речь немного не об этом. Там, как я понял, описывают довольно красивое решение для манипулирования классами, быть ли им синглтонами, мультитонами или обычными классами просто присваивая им интерфейсы. Плюс этакая суперфабрика, любое создание обьекта в приложении нужно вести через нее, иначе не работает в полную силу. Если хоть где-то создать объект напрямую, надежность летит к чертям. Красиво, но я бы поостерегся использовать этот подход на большом длительном проекте, с изменяющейся командой, уж слишком гибко и ненадежно, работает только в идеальном мире, где нет срочных задач, уставших, слабо знакомых с проектом или просто плохих программистов и прочих прелестей способных поломать слишком гибкие и универсальные архитектуры.
И как я уже сказал, речь не об этом, и параметрического создания для синглтонов и использования global там нет. Есть мультитоны, есть фабрика совмещенная с реестром.
И как я уже сказал, речь не об этом, и параметрического создания для синглтонов и использования global там нет. Есть мультитоны, есть фабрика совмещенная с реестром.
Мультитоны это те же яйца только сбоку. Неужели Вы не видите очевидного? В реализации паттерна, который здесь обсуждается, тоже есть такое решение быть ли классу так называемому мультитону или не быть. Внимательней нужно быть.
$connection1 = Object::get( 'DatabaseConnection', '127.0.0.1', 'mrbuzzk', 'abcdefgh' );
$connection2 = Object::get( 'DatabaseConnection', '127.0.0.1', 'mrbuzzk', 'abcdefgh', 3306 );
$connection3 = Object::get( 'DatabaseConnection', '192.168.120.1', 'mrbuzzk', 'abcdefgh', 3306 );
ошибся веткой, перенесено выше.
Синглтон с параметрами? Посмотрите в сторону ServiceLocator/Registry.
Ну что сказать, будь это сделано несколько годами ранее — да, круто.
Но сейчас, когда юнит тесты ставят синглтон под большое сомнение, придумывать очередную, реализацию… ну несколько нелогично, что-ли :).
Но сейчас, когда юнит тесты ставят синглтон под большое сомнение, придумывать очередную, реализацию… ну несколько нелогично, что-ли :).
Годами ранее возможности языка не позволяли делать нормальную реализацию. Юнит тесты не ставят под сомнения синглетоны. Проблема создания mock объектов, использующий паттерн синглетон, теоретически решена — нужно только сделать.
Проблема тестирования синглтона в том, что он хранит в себе состояние системы. И создавая юнит тест, мы не можем по сути учесть, в каком состоянии он реально будет использоваться в системе.
Есле же синглтон класс не предполагает хранения состояния, то его можно заменить классом со статическими функциями.
Есле же синглтон класс не предполагает хранения состояния, то его можно заменить классом со статическими функциями.
Не понятно что имеется в виду под 'хранит состояние системы'. Создовать God object с его помощью никто не намеревается. Возможность влиять на механизм создания объекта типа синглетон (а значит и его состояния) у нас тоже есть.
По-прежнему не вижу никаких проблем.
По-прежнему не вижу никаких проблем.
хех, никто не намеревается… Как показывает практика, если что то можно испортить — то оно будет испорченно (в затяжной разработке — так точно).
Допустим Ваш синглтон имеет три состояния. Что это значит? А это значит, что колличество юнит тестов для всех использующих его функций придёться увеличить в три раза. Т.к. Выж не знаете, в каком состоянии синглтон туда доберётся.
А так, да, проблем нет, всё отлично
Допустим Ваш синглтон имеет три состояния. Что это значит? А это значит, что колличество юнит тестов для всех использующих его функций придёться увеличить в три раза. Т.к. Выж не знаете, в каком состоянии синглтон туда доберётся.
А так, да, проблем нет, всё отлично
Опять не понимаю о чем Вы. Конкретный пример из статьи: у меня есть класс синглетон Db. В конкретном юнит тесте мне не нужно:
a) Что бы не происходило соединение с реальной базой данных.
б) Подставлять нужный мне результат метода ::select.
Все это осуществляется. Какие состояния еще нужно мне знать не пойму.
a) Что бы не происходило соединение с реальной базой данных.
б) Подставлять нужный мне результат метода ::select.
Все это осуществляется. Какие состояния еще нужно мне знать не пойму.
Вы говорите о частном случае. На самом деле, кроме соединения и выборки, могут присутствовать следующие моменты (не в Вашем конкретном примере, а в реальной жизни) — Ошибки, оставшиеся в наследство от предыдущих операций, включённая транзакция, параметры соединения с базой и так далее.
Т.е. Ваша защита выглядит так — «тут у нас демо-класс на 2 функции, и вот скажите, что с ним может случится?»
Т.е. Ваша защита выглядит так — «тут у нас демо-класс на 2 функции, и вот скажите, что с ним может случится?»
Вы, простите, еще раз что хотите то сказать? Объект класса реализующий интерфейс взаимодействия с БД порожденный синглетоном ничем не отличается от такого же объекта порожденного фабрикой.
Да, для юнит тестов нужно нивелировать ряд факторов, которые могут возникать в реальном окружении а не в тестовом. Это всем известно — какое отношение это все имеет к реализации паттерна, этого я не могу понять.
Да, для юнит тестов нужно нивелировать ряд факторов, которые могут возникать в реальном окружении а не в тестовом. Это всем известно — какое отношение это все имеет к реализации паттерна, этого я не могу понять.
Немного странная статья.
Начиналось «реализация Singleton», закончилось «ой какая то хня получилась, давайте назовем ее Multiton».
Если уж используется global, то Singleton реализуется в 4 строчки, а так выглядит как понты ради понтов.
Начиналось «реализация Singleton», закончилось «ой какая то хня получилась, давайте назовем ее Multiton».
Если уж используется global, то Singleton реализуется в 4 строчки, а так выглядит как понты ради понтов.
Термин Multiton был введен чтобы не рвать отдельным людям шаблон; проходите мимо.
Какой шаблон вы о чем? Писали про одно, закончили другим.
Проходить мимо? А потом в проектах очень радоваться тысячам строкам невнятного странного кода, написанных теми, кто подобного начитается, а еще и скопипастит скорее всего.
Проходить мимо? А потом в проектах очень радоваться тысячам строкам невнятного странного кода, написанных теми, кто подобного начитается, а еще и скопипастит скорее всего.
Вам очень крупно повезет, если Вам придеться читать мой код, а не код программиста реализующий паттерн синглетон за 2 минуты в десять строк кода.
По-моему у вас зашкалило ЧСВ.
Простите, вы считаете крупным везением работать с проектом, при разработке которого, видимо, платят за количество строк кода и не гнушаются запутывать этот элитный мега код всяким сомнительными способами? :)
Я думаю, у автора просто было желание сделать свой велосипед. То что получилось, уже не совсем синглтон (эдакий велосипед с моторчиком), и возможно, где-то и пригодится. Но пытаясь выдать его за чистый синглтон, автор и напарывается на стену непонимания.
А вот назвал бы статью «Использование примесей в php, на примере реализации singleton с плюшками» — отхватил бы, наверное, плюсов.
А вот назвал бы статью «Использование примесей в php, на примере реализации singleton с плюшками» — отхватил бы, наверное, плюсов.
Я считаю крупным везением работать с хорошо документированным и продуманным кодом. Лично Вы можете дальше продолжать использовать свой синглетон в четыре строчки кода — никто же не запрещает).
Ваш код омерзителен.
Глобальные переменные в классах, зоопарк из стилей форматирования, чрезмерное усложнение, проглоченные исключения и все это при беглом взгляде по диагонали.
Судя по вашему тону и по тому как вас прет от вашего «хорошего документированого кода» это уже клиническое и лечению не подлежит. К вам лишь одна просьба пишите свой говнокод на здоровье, но только не надо потом выкладывать его в паблик, а то ведь неокрепшие умы увидят и возьмут на вооружение
Глобальные переменные в классах, зоопарк из стилей форматирования, чрезмерное усложнение, проглоченные исключения и все это при беглом взгляде по диагонали.
Судя по вашему тону и по тому как вас прет от вашего «хорошего документированого кода» это уже клиническое и лечению не подлежит. К вам лишь одна просьба пишите свой говнокод на здоровье, но только не надо потом выкладывать его в паблик, а то ведь неокрепшие умы увидят и возьмут на вооружение
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация шаблона проектирования Singleton на PHP 5.4