Базовые классы CodeIgniter, почему это?

Question

Многие фреймворки решили использовать этот подход: заставить пользователя расширять класс базового контроллера (если вы хотите создать новый контроллер) или расширять класс базовой модели (если вы хотите создать новую модель). ).

Давайте посмотрим на код базового класса контроллера CodeIgniter:

/**
 * Constructor
 */
public function __construct()
{
    self::$instance =& $this;

    // Assign all the class objects that were instantiated by the
    // bootstrap file (CodeIgniter.php) to local class variables
    // so that CI can run as one big super object.
    foreach (is_loaded() as $var => $class)
    {
        $this->$var =& load_class($class);
    }
    $this->load =& load_class('Loader', 'core');

    $this->load->initialize();

    log_message('debug', "Controller Class Initialized");
}

Что это делает? Ну, насколько я вижу, это просто позволяет нам использовать $this->load->... например.

Давайте посмотрим на магический метод __get() базового класса модели:

/**
 * __get
 *
 * Allows models to access CI's loaded classes using the same
 * syntax as controllers.
 *
 * @param   string
 * @access private
 */
function __get($key)
{
    $CI =& get_instance();
    return $CI->$key;
}

Он делает то же самое. Что теперь дает этот способ ведения дел?

PRO

• Вы можете получить доступ к полезным классам CI, набрав $this->....

CONS

• Вы должны заставить пользователя расширять базовый класс
• Вы должны заставить пользователя вызвать parent::__construct() в конструкции класса
• get_instace() зарезервировано
• $this->instance переопределение вызывает фатальную ошибку
• Вы в основном повторили один и тот же код как в базовом классе Model, так и в базовом классе Controller

Теперь давайте рассмотрим другой подход:

Создайте статический класс, такой как App, который выполняет все действия базового контроллера: Например, $this->load->... будет App::load->....

Теперь снова рассмотрим плюсы и минусы:

PRO

• Вы можете получить доступ к полезным классам CI App::....
• Вы не должны заставить пользователя расширять базовый класс
• Вы не должны заставлять пользователя вызывать parent::__construct() в конструкции класса
• нет имя метода или имя свойства зарезервированы
• Вы можете использовать приложение как в модели, так и в контроллере

CONS

• У вас больше нет $this-> сексуального синтаксиса ???

ВОПРОС

Здесь возникает реальный вопрос: будет ли второй подход лучше или хуже по сравнению с КИ? Почему?

Answer 1

PRO

• Вы можете получить доступ к полезным классам CI с помощью App :: ....
• Вам не нужно заставлять пользователя расширять базовый класс
• Вам не нужно заставлять пользователя вызывать parent :: __ construct () в конструкции класса. Нет методов
• Имя или имя свойства зарезервированы

Это не совсем верно.CI никогда не заставляет dev расширять базовый класс.Все основные функциональные возможности инфраструктуры могут быть легко расширены.Вы можете иметь MY_Controller.php в папке application/core, содержать собственный базовый класс, например:

Front_Controller extends CI_Controller{
  // Share common properties or functionalities across front/public controllers here
}

Admin_Controller extends CI_Controller{
  // Share common properties or functionalities across administrative controllers here
}

Тогда parent::parent_method() очень распространен в PHP.В большинстве случаев этот синтаксис будет использоваться в других местах, если вы действительно используете ОО-дизайн в своем приложении.Это позволяет вам добавлять функциональность в подкласс, не теряя унаследованную функциональность от родительского класса.

Итак, отвечая на ваш вопрос:

Здесь возникает реальный вопрос: будет ли второйлучше или хуже подход по сравнению с КИ?Почему?

Обе попытки можно считать законными, атм.Потому что: 1) нет проверки целостности (что-то вроде instanceof CI_Controller в PHP 5 или is_a для PHP4) в CI bootstrap, 2) И, CI не заставляет вас возвращать что-либо из метода действия контроллера(объект Response, как, например, в SF).

То есть, вы можете иметь произвольный класс в качестве контроллера.На самом деле вам не нужно было оборачивать функциональность основного контроллера в статический класс, никто не мешал вам использовать get_instance()->load->library('foo') и get_instance()->load->database() в этом произвольном классе.