2009-07-20 2 views
16

Следующий код из учебника (http://net.tutsplus.com/php/creating-a-php5-framework-part-1/), а не мой.Дизайн шаблона реестра ... хороший или плохой?

У меня есть несколько вопросов по поводу этого кода ...

  • В статье утверждается, что использует «реестр шаблон проектирования»; что универсальное название этого дизайна в отрасли?
  • Есть ли другой подобный вариант, который будет лучшим вариантом?
  • Является ли эта модель считающейся хорошей практикой для реализации в контексте структуры MVC?

Я просто хочу выяснить, следует ли использовать этот шаблон проектирования в моей реализации структуры MVC. Благодаря!

<?php 
/** 
* The PCARegistry object 
* Implements the Registry and Singleton design patterns 
* @version 0.1 
* @author Michael Peacock 
*/ 
class PCARegistry { 

/** 
* Our array of objects 
* @access private 
*/ 
private static $objects = array(); 

/** 
* Our array of settings 
* @access private 
*/ 
private static $settings = array(); 

/** 
* The frameworks human readable name 
* @access private 
*/ 
private static $frameworkName = 'PCA Framework version 0.1'; 

/** 
* The instance of the registry 
* @access private 
*/ 
private static $instance; 

/** 
* Private constructor to prevent it being created directly 
* @access private 
*/ 
private function __construct() 
{ 

} 

/** 
* singleton method used to access the object 
* @access public 
* @return 
*/ 
public static function singleton() 
{ 
    if(!isset(self::$instance)) 
    { 
     $obj = __CLASS__; 
     self::$instance = new $obj; 
    } 

    return self::$instance; 
} 

/** 
* prevent cloning of the object: issues an E_USER_ERROR if this is attempted 
*/ 
public function __clone() 
{ 
    trigger_error('Cloning the registry is not permitted', E_USER_ERROR); 
} 

/** 
* Stores an object in the registry 
* @param String $object the name of the object 
* @param String $key the key for the array 
* @return void 
*/ 
public function storeObject($object, $key) 
{ 
    require_once('objects/' . $object . '.class.php'); 
    self::$objects[ $key ] = new $object(self::$instance); 
} 

/** 
* Gets an object from the registry 
* @param String $key the array key 
* @return object 
*/ 
public function getObject($key) 
{ 
    if(is_object (self::$objects[ $key ])) 
    { 
     return self::$objects[ $key ]; 
    } 
} 

/** 
* Stores settings in the registry 
* @param String $data 
* @param String $key the key for the array 
* @return void 
*/ 
public function storeSetting($data, $key) 
{ 
    self::$settings[ $key ] = $data; 


} 

/** 
* Gets a setting from the registry 
* @param String $key the key in the array 
* @return void 
*/ 
public function getSetting($key) 
{ 
    return self::$settings[ $key ]; 
} 

/** 
* Gets the frameworks name 
* @return String 
*/ 
public function getFrameworkName() 
{ 
    return self::$frameworkName; 
} 


} 

?> 
+0

LOL ... Я встал и проголосовал. Думаю, мой вопрос недостаточно хорош для кого-то. – 2009-07-20 02:16:52

ответ

25

В статье утверждает, что использует «реестр шаблон проектирования»; что универсальное название этого дизайна в отрасли?

Да, но реализация, очевидно, может отличаться. В основном, реестр представляет собой контейнер для общих объектов. В действительно базовой версии вы можете использовать массив. Таким образом, переменную $GLOBALS можно назвать реестром.

Есть ли другой подобный вариант, который был бы лучшим вариантом?

Существует два варианта реестра. Существует глобальный реестр (который является самым распространенным, и это пример). И есть локальный реестр. Локальный реестр передается объектам, которые в нем нуждаются, а не получается через глобальный символ (статический класс, singleton и т. Д.). Локальный реестр имеет более низкую степень сцепления, но также немного более абстрактен, поэтому существует компромисс.

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

Этот образец считается хорошей практикой для реализации в контексте структуры MVC?

Это обычная практика. Если это хорошо или плохо, это решение. Лично я готов принять некоторую сложность взамен развязки, но ymmv.

5

Я считаю, что в целом говоря, нет действительно такой тик как «плохая модель». При этом некоторые методы следует использовать более экономно, чем другие, а понятие глобального реестра - это тот, который часто бывает менее элегантным. Проблема заключается в том, что зависимости между заданными объектами обрабатываются с помощью адресной адресации, которая сродни простому использованию глобальных переменных, а не косвенной стратегией путем предоставления зависимостей, что обычно называется инъекцией зависимостей.

Как это может повлиять на повторное использование и гибкость программного обеспечения на самом деле очень ясно. Рассмотрим обработчик запросов, который интегрируется с поставщиком OAuth2 для аутентификации. Если вы определяете объект с четко определенным интерфейсом для запросов к этому провайдеру OAuth2, у вас есть возможность изменить поставщика в будущем, создав еще один объект, который реализует один и тот же интерфейс.

Теперь предположим, что для обсуждения вашей первой реализации необходимо получить доступ к Facebook. Но затем на следующей неделе вы принимаете решение о том, что вы также должны поддерживать Yahoo, который реализует OAuth2 таким образом, который следует за спецификацией более тесно, чем Facebook, фактически использует JSON в запросе токена авторизации, а не в парах значений имени. И, кроме того, существуют разные пары URL-адресов и ключей, а также то, что нужно сохранить.

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

Коснитесь, что вы сработали, уменьшили количество необходимого кода и в конечном итоге сделали ваше программное обеспечение более дешевым, лучшим и быстрым.

С учетом сказанного, бывают случаи, когда два шаблона не являются взаимозаменяемыми. Скажем, например, вы создаете структуру, которая привязывает обработчики событий к узлам XML-документа. Вы описываете расположение узлов в XML-документе, используя XPath или реализацию JQuery селекторов CSS. Но для присоединения обработчика событий вам также необходимо обратиться к некоторому коду. Предпочтительно, вы будете ссылаться на какой-то метод какого-либо объекта - ну, нет никакого способа найти этот «некоторый объект», не указывая ему имя, поэтому теперь вам нужен локатор сервисов, поэтому вы можете искать вещи по имени. Но имейте в виду, что даже в этом примере ничего не говорится о том, что имя должно быть глобальным.

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

Смежные вопросы