Если я не ошибаюсь в спецификации протокола TCP минимальное значение UTO равно одной секунде. Так что тут еще под вопросом как это было реализовано в PeclMemcache.
Не переживайте по поводу отдельных комментариев — с отдельными товарищами и их подходу к проектированию я уже успел столкнуться в комментариях к другой статье.
А в общем идея Ваша мне понравилась — что-то полезное для себя извлек.
Вот только меня смущает этот момент: SequentialCache — представьте, что у вас есть хранилище, которое иногда падает или просто недоступно. Например, оно может иногда выводиться на обслуживание, перезапускаться и т.д. При этом, данные приложение хочет получать всегда. Для покрытия этой ситуации можно использовать SequentialCache, примерно с таким конфигом:
Вы представляете сколько будет ожидать приложение подключения к упавшему серверу кеширования прежде чем отвалится по timeout-у? Это только увеличит время получения данных а не уменьшит его.
Я считаю крупным везением работать с хорошо документированным и продуманным кодом. Лично Вы можете дальше продолжать использовать свой синглетон в четыре строчки кода — никто же не запрещает).
Вы, простите, еще раз что хотите то сказать? Объект класса реализующий интерфейс взаимодействия с БД порожденный синглетоном ничем не отличается от такого же объекта порожденного фабрикой.
Да, для юнит тестов нужно нивелировать ряд факторов, которые могут возникать в реальном окружении а не в тестовом. Это всем известно — какое отношение это все имеет к реализации паттерна, этого я не могу понять.
Не понятно что имеется в виду под 'хранит состояние системы'. Создовать God object с его помощью никто не намеревается. Возможность влиять на механизм создания объекта типа синглетон (а значит и его состояния) у нас тоже есть.
Годами ранее возможности языка не позволяли делать нормальную реализацию. Юнит тесты не ставят под сомнения синглетоны. Проблема создания mock объектов, использующий паттерн синглетон, теоретически решена — нужно только сделать.
Мультитоны это те же яйца только сбоку. Неужели Вы не видите очевидного? В реализации паттерна, который здесь обсуждается, тоже есть такое решение быть ли классу так называемому мультитону или не быть. Внимательней нужно быть.
Смотря с какой точки зрения на это смотреть. Я сторонник слабо-связанной архитектуры. В таком случае наш класс Db сам по себе и не зависит ни от кого в создании и конфигурации.
В крайнем случае можно использовать MessageBus как связующий компонент для конфигурации отдельных компонентов.
И если у меня появятся две новые базы я просто изменю базовый класс.
Первоочередной принцип программирования: не засорять пространство видимости имен в том числе и глобальное. В данном случае этот принцип соблюдается. Запись в глобасы… Вы уж простите, даже формулируется не академически.
В общем никто не запрещает использовать его как обычный синглетон. В моей практике был такой случай, когда разработчикам понадобился еще один интерфейс подключения к ведомой СУБД. Решение потрясало своей простотой и «изящностью»: был создан класс DB2 — копия DB только с необходимыми настройками,
Это не академический подход, как некоторые тут говорят, но зато в реальном проекте.
А в общем идея Ваша мне понравилась — что-то полезное для себя извлек.
Вот только меня смущает этот момент:
SequentialCache — представьте, что у вас есть хранилище, которое иногда падает или просто недоступно. Например, оно может иногда выводиться на обслуживание, перезапускаться и т.д. При этом, данные приложение хочет получать всегда. Для покрытия этой ситуации можно использовать SequentialCache, примерно с таким конфигом:
Вы представляете сколько будет ожидать приложение подключения к упавшему серверу кеширования прежде чем отвалится по timeout-у? Это только увеличит время получения данных а не уменьшит его.
Так что расслабтесь. А с глобальными переменными (собственно она там одна) Вы меня в очередной посмешили.
Да, для юнит тестов нужно нивелировать ряд факторов, которые могут возникать в реальном окружении а не в тестовом. Это всем известно — какое отношение это все имеет к реализации паттерна, этого я не могу понять.
a) Что бы не происходило соединение с реальной базой данных.
б) Подставлять нужный мне результат метода ::select.
Все это осуществляется. Какие состояния еще нужно мне знать не пойму.
По-прежнему не вижу никаких проблем.
Другие люди так не считают.
В крайнем случае можно использовать MessageBus как связующий компонент для конфигурации отдельных компонентов.
И если у меня появятся две новые базы я просто изменю базовый класс.
Это не академический подход, как некоторые тут говорят, но зато в реальном проекте.