Разработка ООП и хуки

Я в настоящее время работаю над созданием своего первого OOP плагина для WordPress.

Чтобы немного помочь со структурой, я искал и нашел шаблон, который помогает мне настроить основы.

В Main.php есть метод, который загружает JS и CSS ресурсы для админки:

/**
 * Зарегистрировать все хуки, связанные с функциональностью
 * админской области плагина.
 *
 * @since    0.1.0
 * @access   private
 */
private function define_admin_hooks() {

  $plugin_admin = new Admin\Controller( $this->get_plugin_name(), $this->get_version(), $this->get_plugin_path() );

  $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_styles' );
  $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_scripts' );

}

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

Вот пример с настройкой CPT и добавленной страницей настроек:

/**
 * Зарегистрировать все хуки, связанные с функциональностью
 * админской области плагина.
 *
 * @since    0.1.0
 * @access   private
 */
private function define_admin_hooks() {

  $plugin_admin = new Admin\Controller( $this->get_plugin_name(), $this->get_version(), $this->get_plugin_path() );

  $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_styles' );
  $this->loader->add_action( 'admin_enqueue_scripts', $plugin_admin, 'enqueue_scripts' );

  $interactWithVimeo = new Admin\InteractWithVimeo();
  $this->loader->add_action ( 'admin_init', $interactWithVimeo, 'setCredentials');

  $cpt = new Admin\CustomPostType();

  // Создать пользовательский тип записи
  $this->loader->add_action ( 'init', $cpt, 'create_post_type' );

  // Удалить действия строк записей
  $this->loader->add_filter ( 'post_row_actions', $cpt, 'remove_row_actions', 10, 2 );

  $settingsPage = new Admin\SettingsPage();

  // Добавить страницу настроек в меню CPT
  $this->loader->add_action ( 'admin_menu', $settingsPage, 'add_settings_page' );
}

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

Что-то вроде:

/**
 * Зарегистрировать все хуки, связанные с функциональностью
 * админской области плагина.
 *
 * @since    0.1.0
 * @access   private
 */
private function define_admin_hooks() {

  $myExensiveClassWithAlotOfMethods = new Admin\MyExensiveClassWithAlotOfMethods();
  $this->loader->add_action ( 'admin_init', $myExensiveClassWithAlotOfMethods, 'init' );

}

А метод init в классе тогда содержит все хуки, которые нужны классу.

Это плохая идея? Понятно, что есть разные способы это сделать. Мне просто интересно, какой подход кажется более соответствующим шаблону.

Sally CJ поднимает хороший вопрос в своем комментарии, что, вероятно, лучше, если каждый класс будет инициализировать свои собственные действия и фильтры.

Я работал с тем же шаблоном в течение некоторого времени и создал свою собственную версию этого шаблона на GitHub.

В этой версии у меня есть Back\Hooks и General\Hooks, оба Singleton и передаются Loader. Вот как выглядит General\Hooks в одном из проектов:

<?php

namespace ACME\General;

class Hooks
{
        protected static $instance;
        protected $loader;

        public static function getInstance($loader)
        {
                if (self::$instance === null) {
                        self::$instance = new self($loader);
                }
                return self::$instance;
        }

        protected function __construct($loader)
        {
                $this->loader = $loader;
        }

        public function run()
        {
                $this->addActions();
                $this->addFilters();
        }

        protected function addActions()
        {
                AdvancedCustomFields\Options::add($this->loader);
                $this->loader->addAction('init', Shortcode\News::class, 'init');
                $this->loader->addAction('init', Shortcode\Courses::class, 'init');
                $this->loader->addAction('wp_footer', WooCommerce\Foo::class, 'print_modal');
                // и многие другие
        }

        protected function addFilters()
        {
                $this->loader->addFilter('the_content', Bar\Baz::class, 'filter_the_content', 999);
                // и многие другие
        }
}

Теперь в случае AdvancedCustomFields\Options я уже передаю загрузчик и делаю инициализацию внутри этого класса, делая то же самое для всех остальных случаев, вероятно, будет намного чище.

General\Shortcode\News выглядит так:

<?php

namespace ACME\General\Shortcode;

class News
{
    public static function init()
    {
        add_shortcode('acme_news', [__CLASS__, 'render']);
    }

    public static function render($raw_atts = [], $content = null, $tag = '')
    {
        $raw_atts = array_change_key_case((array)$raw_atts, CASE_LOWER);
        $atts = shortcode_atts([
            'size' => 'large',
            'amount' => '4',
            'offset' => '0',
            'exclude' => '',
        ], $raw_atts, $tag);

        /* фильтровать $atts */
        $atts['amount'] = intval($atts['amount']);
        $atts['offset'] = intval($atts['offset']);

        /* получить результат */
        $result="";
        // фактический код, выполняющий WP_Query и т.д.
        // никогда не выводится напрямую, а только сохраняется в $result

        return $result;
}