Как из двух строчек кода сделать 200, и почему так делать надо

Migesco\Configurator::attachFiles('/e-cryptex.js', '/wp-content/themes/tol-child/js/child_realforex.js');

Не хотелось бы вас расстраивать, но держите патч:

-<script src="e-cryptex.js"></script>
-<script src="wp-content/themes/tol-child/js/child_realforex.js"></script>
+<script src="/e-cryptex.js"></script>
+<script src="/wp-content/themes/tol-child/js/child_realforex.js"></script>

Посмотрел я на этот код, и моё чувство прекрасного взбунтовалось:
человек не знакомый с WordPress ни чего не поймёт — придётся лезть в справочник что бы понять назначение функций wp_register_script() и wp_enqueue_script()
явно делается одно и то же два раза подряд, аргументы только разные — нарушается DRY

1. Теперь не поймет в том числе и человек знакомый с Wordpress, в любом случае придется лезть в код и разбираться
2. DRY вовсе не про то, чтобы каждые две повторяющиеся строчки оборачивать в отдельный класс. Тем более что по факту результирующий код практически не уменьшился (потому что он и изначально в основном состоял из аргументов)

По итогу — обе поставленные цели не достигнуты

Решение было протестировано для главной страницы и там оно работало, позже выяснилось что для страниц с адресом example.com/about, решение не работало, потому что браузер пытался подгрузить example.com/about/e-cryptex.js и браузер получал — ошибку 404, потому что файл реально лежал в корне — example.com/e-cryptex.js .

Насколько я знаю HTML, для этого достаточно немного изменить путь

+<script src="/e-cryptex.js"></script>
+<script src="/wp-content/themes/tol-child/js/child_realforex.js"></script>

явно делается одно и то же два раза подряд, аргументы только разные — нарушается DRY

человек не знакомый с WordPress ни чего не поймёт — придётся лезть в справочник что бы понять назначение функций wp_register_script() и wp_enqueue_script()
явно делается одно и то же два раза подряд, аргументы только разные — нарушается DRY

+$traderoomScriptFiles = array(
+    (new Migesco\WebResource(ECRYPTEX_JS))
+        ->setSource('/e-cryptex.js'),
+    (new Migesco\WebResource('child_realforex'))
+        ->setSource('/wp-content/themes/tol-child/js/child_realforex.js')
+        ->setDependency(array(ECRYPTEX_JS))
+);
+Migesco\Configurator::attachFiles($traderoomScriptFiles);
 ?>

/**
+     * @param string $name
+     * @return WebResource
+     */

Решение было протестировано для главной страницы и там оно работало, позже выяснилось что для страниц с адресом example.com/about, решение не работало, потому что браузер пытался подгрузить example.com/about/e-cryptex.js и браузер получал — ошибку 404, потому что файл реально лежал в корне — example.com/e-cryptex.js .

человек не знакомый с WordPress ни чего не поймёт — придётся лезть в справочник что бы понять назначение функций wp_register_script() и wp_enqueue_script()

явно делается одно и то же два раза подряд, аргументы только разные — нарушается DRY

'/wp-content/themes/tol-child/js/child_realforex.js',

get_template_directory_uri()

plugin_dir_url()

class WebResource
{
    public $dependency = array();
	
    public function setDependency($dependency)
    {
        $isArray = is_array($dependency);
        if ($isArray) {
            $this->dependency = $dependency;
        }
        return $this;
    }
}

class WebResource
{
    private $dependency;
	
    public function setDependency($dependency)
    {
	$this->dependency = (is_array($dependency) ? $dependency : null)
	return $this;
    }
}

class WebResource
{
    private $dependency;
	
    public function setDependency(?array $dependency): self
    {
	$this->dependency = $dependency;
	return $this;
    }
}

1. Мотивация. Если я правильно понял, то вы пытались сделать код более «универсальным и гибким». Но в итоге только усложнили ситуацию.
   
   

   человек не знакомый с WordPress ни чего не поймёт

   
   Ваш проект — плагин для WordPress. Какова вероятность, что его поддержку доверят человеку который не знаком с этой CMS? Это ж как доверить доработку сайта на php человеку, который не знаком с php.
   
   Кроме того, открыть справку по функции WP, куда проще, чем лезть в чужой код и пытаться розобраться в его работе.
   
   В итоге, я, как потенциальный исполнитель после вас, буду вынужден потратить несколько часов на то, чтобы просто понять что это за код, что он делает и почему не использовались общепринятые решения.
   
   
2. Результат, даже менее гибок, чем изначальный.
   
   Предположим, что я — разработчик, которому передали проект. Я человек ответственный и решил, действовать по вашему сценарию. Весь новый функционал вынес в отдельный файл. И подключать буду так же, как вы, чтобы соблюдать общий подход.
   
   Мне нужно подключить файл в подвал страницы. И как мне это сделать? Судя по вашему коду, это не возможно, так как ваш код не предусматривает передачу параметра $in_footer в wp_enqueue_script.
   
   Или например, как мне указать версию для файла? Вот у меня в ТЗ указано, что при подключении файла обязательно необходимо указывать его версию. В вашем решении такой возможности нет.
   
   В итоге, при здаче, я смогу отметить 20 часов работы как «Отрефакторил код предыдущего разработчика, и привёл его к виду в соответствии с стандартами разработки под WordPress». Хоят по факту — я просто удалю ваше решение и заменю его на два вызова wp_enqueue_script