Года три - четыре назад про шаблоны проектирования на собеседовании можно было и не спрашивать, все равно никто ничего ответить не мог. Сегодня все поменялось. Все открыли для себя шаблоны, уверовали и с бьющей через край энергией прозерлитов бросились нести это знамя в массы. При этом забывая, что (Шаблоны_проектирования != заповеди_господни). И вот уже "недостатки_паттерна_синглтон" должны на собеседовании от зубов отскакивать. Наверное, также как и "преимущества_IoC". Так? Собственно мой сарказм был направлен именно в эту сторону. Паттерны, штука прикладная, рассуждать о них без приложения к конкретному контексту - вещь неблагодарная.
По большому счету, Вы правы, Сергей. Сами по себе шаблоны - не панацея. И я совершенно согласен, что о шаблонах рассуждать нужно в конкретном контексте.
С другой стороны, есть вещи, с которыми программист обязан быть знаком. И паттерны - одна из таких вещей. Вряд ли с этим можно спорить.
Что касается конкретного вопроса о "недостатках синглтона", то ответ совсем не должен отскакивать от зубов. (частично потому, что единственно правильного ответа не существует) Человеку достаточно включить мозги и просто порассуждать вслух.
> (частично потому, что единственно правильного ответа не существует)
Это для тебя не существует. Есть перцы, которые знают правильные ответы на все вопросы. Я вот припоминаю случай, когда интервьюер завернул кандидата, потому что тот не смог назвать "недостатки наследования". Просто интервьюер не любил наследование и любил интерфейсы.
Ну да, есть такие перцы. Но для этого же собеседования и существуют : для интервьюеров - отфильтровать неадекватных кандидатов; для кандидатов - отфильтровать неадекватных работодателей :)
Вашему кандидату можно только позавидовать, что дальше интервью отношения не сложились. Работай они вместе - проблем было бы гораздо больше :)
Использование синглетона вносит в код класса, который его использует, зависимости не описанные через контракт этого класса. Это плохо. Второй недостаток - это глобальное состояние синглетона. Чем оно плохо? Опять же, вносит зависимости, которые трудно отследить.
Другое дело, что иногда этими недостатками можно пренебречь либо они не свегда имеют место быть. Синглетон может не иметь состояния (stateless). А нарушать правило Деметры (вносить скрытые зависимости) может не только синглетон, но и, например, часто используемый в IoC реализациях паттерн Service Locator.
Если они на собеседовании это хотели услышать, то вероятно, я был не прав со своим сарказмом.
Еще можно добавить проблему инициализации - можно использовать динамический экземпляр, а можно статический. Статическая инициализация - это хорошо, но если синглтон зависит от какого-то ресурса, который инициализируется позже, то статическая инициализация невозможна. Или, например, если в программе используются несколько синглтонов, зависящих друг от друга - то же самое. При динамической инициализации эту проблему можно решить, но тогда возникает необходимость каждый раз, когда клиентскому классу требуется ссылка на синглтон, проверять создан ли уже синглтон или нет. Если требуется обеспечить многопоточный доступ к синглтону, то в этом месте нужно еще и использовать синхронизацию, нпаример, мьютексы. Плюс при динамической инициализации возникает вопрос - когда и кто будет вызывать деструктор этого синглтона. При статической инициализации такой проблемы нет.
Если поискать в сети, то иногда еще упоминается, что использование синглтона непрозрачно для других программистов - нельзя использовать оператор new для получения экземпляра, как обычно. Следовательно, может возникнуть какое-то недопонимание и ошибки использования.
Отвечать надо просто:
ОтветитьУдалить"Отче наш, иже еси на небеси. Да святится имя твое. Да придет царствие твое..." далее по тексту. :)
Извините, Сергей, но шутки я не понял :)
ОтветитьУдалитьГода три - четыре назад про шаблоны проектирования на собеседовании можно было и не спрашивать, все равно никто ничего ответить не мог.
ОтветитьУдалитьСегодня все поменялось. Все открыли для себя шаблоны, уверовали и с бьющей через край энергией прозерлитов бросились нести это знамя в массы. При этом забывая, что (Шаблоны_проектирования != заповеди_господни).
И вот уже "недостатки_паттерна_синглтон" должны на собеседовании от зубов отскакивать. Наверное, также как и "преимущества_IoC". Так?
Собственно мой сарказм был направлен именно в эту сторону.
Паттерны, штука прикладная, рассуждать о них без приложения к конкретному контексту - вещь неблагодарная.
По большому счету, Вы правы, Сергей. Сами по себе шаблоны - не панацея. И я совершенно согласен, что о шаблонах рассуждать нужно в конкретном контексте.
ОтветитьУдалитьС другой стороны, есть вещи, с которыми программист обязан быть знаком. И паттерны - одна из таких вещей. Вряд ли с этим можно спорить.
Что касается конкретного вопроса о "недостатках синглтона", то ответ совсем не должен отскакивать от зубов. (частично потому, что единственно правильного ответа не существует) Человеку достаточно включить мозги и просто порассуждать вслух.
> (частично потому, что единственно правильного ответа не существует)
ОтветитьУдалитьЭто для тебя не существует. Есть перцы, которые знают правильные ответы на все вопросы. Я вот припоминаю случай, когда интервьюер завернул кандидата, потому что тот не смог назвать "недостатки наследования". Просто интервьюер не любил наследование и любил интерфейсы.
Ну да, есть такие перцы. Но для этого же собеседования и существуют : для интервьюеров - отфильтровать неадекватных кандидатов; для кандидатов - отфильтровать неадекватных работодателей :)
ОтветитьУдалитьВашему кандидату можно только позавидовать, что дальше интервью отношения не сложились. Работай они вместе - проблем было бы гораздо больше :)
А я ничего не знаю про этот паттерн, и у меня все хорошо =).
ОтветитьУдалитьА расскажите мне, неудачнику, в чём всё-таки заключаются недостатки синглетона?
ОтветитьУдалитьИспользование синглетона вносит в код класса, который его использует, зависимости не описанные через контракт этого класса. Это плохо.
ОтветитьУдалитьВторой недостаток - это глобальное состояние синглетона. Чем оно плохо? Опять же, вносит зависимости, которые трудно отследить.
Другое дело, что иногда этими недостатками можно пренебречь либо они не свегда имеют место быть.
Синглетон может не иметь состояния (stateless). А нарушать правило Деметры (вносить скрытые зависимости) может не только синглетон, но и, например, часто используемый в IoC реализациях паттерн Service Locator.
Если они на собеседовании это хотели услышать, то вероятно, я был не прав со своим сарказмом.
Еще можно добавить проблему инициализации - можно использовать динамический экземпляр, а можно статический. Статическая инициализация - это хорошо, но если синглтон зависит от какого-то ресурса, который инициализируется позже, то статическая инициализация невозможна. Или, например, если в программе используются несколько синглтонов, зависящих друг от друга - то же самое. При динамической инициализации эту проблему можно решить, но тогда возникает необходимость каждый раз, когда клиентскому классу требуется ссылка на синглтон, проверять создан ли уже синглтон или нет. Если требуется обеспечить многопоточный доступ к синглтону, то в этом месте нужно еще и использовать синхронизацию, нпаример, мьютексы. Плюс при динамической инициализации возникает вопрос - когда и кто будет вызывать деструктор этого синглтона. При статической инициализации такой проблемы нет.
ОтветитьУдалитьЕсли поискать в сети, то иногда еще упоминается, что использование синглтона непрозрачно для других программистов - нельзя использовать оператор new для получения экземпляра, как обычно. Следовательно, может возникнуть какое-то недопонимание и ошибки использования.