L!MP, А почему с паттерном Регистри есть проблема отложенной инициализации?
А ещё нашёл статью, хотел бы услышать твоё мнение о ней, я то с паттернами не особо пока касался.
Singleton представляет собой класс со статическим интерфейсом, что делает его доступным глобально. Пожалуй, это основная идея использования «одиночки». Удобно иметь доступ к объекту класса из любой части приложения. Например, класс работы с базой данных будет очень удобен, если будет доступен глобально, но у Singleton есть еще одна особенность, которая делает его неприменимым в данном случае. Эта особенность – возможность иметь только один объект от класса реализующего шаблон Singleton. А я если наше приложение должно соединяться с двумя разными серверами БД? В таком случае одного объекта будет недостаточно, но иметь глобальный доступ к объектам все равно хочется. Вот тут нам и поможет паттерн Registry.
Пример реализации Registry
Сам по себе, Registry – этот все тот же Singleton, с тем же статическим интерфейсом. Его объект обеспечивает связь с другими объектами и делает их доступными глобально. Чтобы было понятно, о чем пойдет речь, приведу код класса, реализующего этот паттерн. Код на PHP.
class Registry
{
/**
* Singleton registry instance
* @var Singleton registry instance
*/
static private $_instance = null;
/**
* Hash table
* @var array
*/
private $_registry = array();
/**
* Get Registry instanse
*
* @return Singleton registry instance
*/
static public function getInstance() {
if (is_null(self::$_instance)) {
self::$_instance = new self;
}
return self::$_instance;
}
/**
* Save an object by key into registry
*
* @param integer|string $key
* @param object $object
* @return void
*/
static public function set($key, $object) {
self::getInstance()->_registry[$key] = $object;
}
/**
* Get an object by key from registry
*
* @param integer|string $key
* @return object
*/
static public function get($key) {
return self::getInstance()->_registry[$key];
}
/**
* Private constructor
* @return void
*/
private function __construct() {
}
/**
* Disallow cloning
* @return void
*/
private function __clone() {
}
}Ну и небольшой пример использования. Представим, что у нас есть некоторый класс Foo, объект которого должен быть доступен глобально, но делать из этого класса одиночку мы не можем или не хотим.
Registry::set('foo', new Foo());
Registry::get('foo')->bar();Регистрируем объект класс Foo через статический метод Registry::set(), после чего имеем возможность получить доступ к методу Foo::bar() через статический метод реестра Registry::get().
Уверен, что если вы работали с какими-нибудь фреймворками, то не могли не встречать реализацию Registry. Так что, скорее всего, я ничего принципиально нового вам не открыл
.gif)
.Плюсы
В принципе, все плюсы я уже перечислил. Глобальный доступ – это удобно. Нет необходимости плодить множество одиночек. Теперь все они в одном месте и под строгим контролем. Ну а там, где использование паттерна Singleton, ввиду ряда причин невозможно, Registry будет выходом из ситуации.
Минусы
Минусы тоже есть, куда уж без них.
Во-первых, использование глобальных объектов может привести к тому, что проект превратиться в немасштабируемый.
Во-вторых, пусть Registry, в какой-то степени, призван заменить множество «одиночек», тем не менее, он не обеспечивает наличие только одного объекта зависимого класса. Даже если в реализации Registry мы предупредим создание двух объектов оного класса, никто не запретит разработчику действовать в обход нашего реестра.
Ну а в-третьих, мы порождаем новые зависимости. Объекты зависят от реестра и от ключей реестра. Это тоже может стать причиной плохой масштабируемости проекта.
Оригинал -> здесь.
Лично я тут ничего сверх чего-то не вижу, обычный статический класс с закрытым от общего взора "полем" $_instance (если называть по тру ООП).
А зачем использовать паттерны? Чтобы не изобретать велосипед?
Наткнулся на паттерн Strategy (направлен на реализацию взаимозаменяемости алгоритмов), вот он впечатлил, лично я, будучи пока профаном в ООП, тоже замутил бы на if-else или try-catch и понаписал бы кучу кода.
А какой паттерн выбрал ты? и можно узнать, почему? Я просто скоро начну новый проект писать, где собираюсь по полной использовать ООП, и твоя "моральная" помощь не помешала бы, смотрю ты шариш.
