Подтвердить что ты не робот

Дизайн дизайна реестра... хороший или плохой?

Следующий код из учебника (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;
}


}

?>
4b9b3361

Ответ 1

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

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

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

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

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

Является ли эта модель считающейся хорошей практикой для реализации в контексте структуры MVC?

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

Ответ 2

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

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

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

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

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

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

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