Оглавление.

А теперь нужен класс, который предоставляет доступ к настройкам и общим библиотекам, попутно настраивая их. От него можно наследовать контроллеры и модели, чтобы получить этот доступ.

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

Мне проще, у меня нет зависимости от объектов (каламбур), я волен использовать любые инструменты. А в данном случае свою любимую статику. Не понимаю, почему её значение так принижается. Это же удобно и многое упрощает. Особенно если это сборка автономных библотек.

Оставим лирику. Вот так пока будет устроен класс сборки (я пока туда сунул класс вьюшки для наглядности).
Core/Libs/Assembly.php

<?php

namespace Core\Libs;

/** 
 * Класс Assembly
 * 
 * NOTE: Requires PHP version 5.5 or later   
 * @author phpforum.su
 * @copyright © 2016
 * @license WTFPL (http://www.wtfpl.net)
 */ 
class Assembly
{
    protected static $config;
    
    /**
    * Установка конфиги
    *
    * @return void
    */  
    public static function setting($config)
    {
        self::$config = $config;
    }
    
    /**
    * Отображение
    *
    * @return object
    */  
    public static function getView()
    {
        $view = new \Core\Libs\View\Master(self::$config);
        // Тут можно настраивать либу или внедрять в неё зависимости
        return $view;
    }  
}

Его нужно задействовать в системе, пусть этим занимается фронт-контроллер:
Core/FrontController.php

class FrontController
{
    /**
    * Запуск
    *
    * @param object $config
    *
    * @return void
    */  
    public static function run($config = null)
    {
        $config = is_object($config) ? $config->getConfig() : [];
     
        if (isset($config['debug']) && false === $config['debug']) {
            set_error_handler(['\Core\FrontController', 'error500']);
        }
        // Сборка библиотек
        \Core\Libs\Assembly::setting($config);
        
        $page = takeGET('page');
        $controllerName = self::prepare($page);
        $controller = '\App\Controllers\\'. $controllerName .'Controller';
     
        $action = takeGET('action', 'index');
        $actionName = self::prepare($action);
        $action = 'action'. $actionName;        
     
        self::callApplication($controller, $action);
    }

А теперь в контроллере страницы, или в любой модели, если их отнаследовать от сборки, можно пользоваться любой, предварительно настроенной библиотекой. Это конечно пока все упрощенно, на уровне заглушки. Позже будет и своего рода снглтон и новые объекты, пока так, чтобы была видна суть.
App/Controllers/ErrorController.php

<?php

namespace App\Controllers;


class ErrorController extends \Core\Libs\Assembly
{  
    public static function action404()
    {
        header("HTTP/1.1 404 Not Found");
        // Тут теперь можно задействовать вьюшку (её пока нет, позже сделаем)
        parent::getView()->render('404');
    }
    
    public static function action500()
    { 
        header("HTTP/1.1 500 Internal Server Error");
        parent::getView()->render('500');
    }    
}

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

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

Можно возразить, что класс распухнет, если будет "большой проект" с кучей библиотек. Но никакой фреймворк от этого не спасет. Даже наоборот, фреймврки обычно тянут за собой все либы, в сборке можно использовать только необходимые. Если их действительно много, то можно разделить этот класс по тематикам. И в конце концов, никто не запрещает использовать внутри тот же DIC. Полная свобода действий.

Впрочем пока рано говорить. Посмотрим, что будет дальше.
Пока это выглядит так:

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.