Pattern Registry – “Реестр”

Сегодня хочу продолжить тему шаблонов проектирования или, как их еще называют, паттернов.

Это вторая по счету заметка и посвящена она будет паттерну Registry, что станет, как я думаю, хорошим и логичным дополнением к первой заметке, в которой речь шла о шаблоне «Одиночка» – Singleton. Ссылку на эту заметку вы можете найти в конце.

Для тех, кто еще ничего не знает о Singleton и не хочет читать мою первую гениальную статью (сарказм, а то мало ли, что подумаете…), я в двух словах поясню, что реализует этот паттерн и для чего.

Singleton представляет собой класс со статическим интерфейсом, что делает его доступным глобально. Пожалуй, это основная идея использования «одиночки». Удобно иметь доступ к объекту класса из любой части приложения. Например, класс работы с базой данных будет очень удобен, если будет доступен глобально, но у Singleton есть еще одна особенность, которая делает его неприменимым в данном случае. Эта особенность – возможность иметь только один объект от класса реализующего шаблон Singleton. А я если наше приложение должно соединяться с двумя разными серверами БД? В таком случае одного объекта будет недостаточно, но иметь глобальный доступ к объектам все равно хочется. Вот тут нам и поможет паттерн Registry.

Пример реализации Registry

Сам по себе, Registry – этот все тот же Singleton, с тем же статическим интерфейсом. Его объект обеспечивает связь с другими объектами и делает их доступными глобально. Чтобы было понятно, о чем пойдет речь, приведу код класса, реализующего этот паттерн. Код на PHP.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<?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, объект которого должен быть доступен глобально, но делать из этого класса одиночку мы не можем или не хотим.

1
2
3

Registry::set('foo', new Foo());
 
Registry::get('foo')->bar();

Регистрируем объект класс Foo через статический метод Registry::set(), после чего имеем возможность получить доступ к методу Foo::bar() через статический метод реестра Registry::get().

Уверен, что если вы работали с какими-нибудь фреймворками, то не могли не встречать реализацию Registry. Так что, скорее всего, я ничего принципиально нового вам не открыл :).

Плюсы

В принципе, все плюсы я уже перечислил. Глобальный доступ – это удобно. Нет необходимости плодить множество одиночек. Теперь все они в одном месте и под строгим контролем. Ну а там, где использование паттерна Singleton, ввиду ряда причин невозможно, Registry будет выходом из ситуации.

Минусы

Минусы тоже есть, куда уж без них.

Во-первых, использование глобальных объектов может привести к тому, что проект превратиться в немасштабируемый.

Во-вторых, пусть Registry, в какой-то степени, призван заменить множество «одиночек», тем не менее, он не обеспечивает наличие только одного объекта зависимого класса. Даже если в реализации Registry мы предупредим создание двух объектов оного класса, никто не запретит разработчику действовать в обход нашего реестра.

Ну а в-третьих, мы порождаем новые зависимости. Объекты зависят от реестра и от ключей реестра. Это тоже может стать причиной плохой масштабируемости проекта.

Подходите ко всему с умом и осознанием правильности принятого решения.

Да пребудет с вами Сила!

Другие паттерны:

• Pattern Strategy – “Стратегия”
• Pattern Singleton – “Одиночка”

Автор: Мурашов Олег
Источник: http://inroot.ru/