Паттерн «Стратегия».

Существует.

Что ты хотел узнать этим вопросом?

паттерн

Я бы хотел узнать в чем недостаток такого подхода? Он похож на mvc, но исключается контроллер. Я не понимаю, зачем нужно это промежуточное звено в виде контроллера в mvc?

но исключается контроллер

В каком месте тут исключается контроллер?

класс, соответствующий этому роуту(пр. Category) и метод(пр. getCategoryList);

Это и есть контроллер, причём именно так оно и реализовано в 99% фреймворков.

mvc

Category это же модель, здесь getCategoryList получает список категорий и отдает шаблону

Ну так getCategoryList и есть контроллер

mvc

А модель где тогда? Контроллер/Модель - классы ведь должны быть

А модель где тогда

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

получает список категорий и отдает шаблону

Ты упускаешь важную деталь, сначала он вынимает параметры запроса. Модель это по определению абстракция данных, она ничего про запросы не знает. Поэтому нужен контроллер (т.е. управитель, организатор работы), который разбирает запрос, запускает модель, результат собирает в ответ и передаёт представлению. Т.е. контроллер выкинуть нельзя никак, можно логику относящуюся к модели и даже к вьюхе запихать в контроллер (и получить портянку в духе php4). В mvc же предлагается выделять логику относящуюся к обработке данных и к представлению данных в отдельные компоненты, а на контроллер остаётся организация их взаимодействия между собой и с внешними событиями.

Нет, это лишь абстракции, а ты про детали реализации

Я не понимаю, зачем нужно это промежуточное звено в виде контроллера в mvc?

BL

… но исключается контроллер.

Распределитель же. Модель работает с данными, шаблонизатор работает с отображением данных, роутер по данным из запроса определяет, кому передать управление. Кто-то ещё должен их всех соединять, иначе один из этих троих будет занят совсем не своим делом. Так вот, этот клей и есть контроллер. А как он выглядит - дело десятое.

Строго говоря, контроллер – это то что стоит на пути данных от view к модели. Т.е. берёт данные из view (когда юзер жмёт submit формы) и модифицирует модель. Наверное, и роутер, и применение параметров фильтрации сюда же можно уложить; хотя что в этих случаях понимается под моделью – вопрос открытый.

А если вьюха не напрямую коннектится к модели (паттерном observer), а имеется специальный код, читающий модель и готовящий данные для вьюхи, этот код называется presenter, а шаблон - MVP. Хотя т.к. контроллер присутствует всегда (вьюха в принципе не знает, как обновлять модель; исключение – говно-анти-паттерн active record), то правильнее было бы называть MVPC.

Т.е. Model —> [Presenter] —> View —> Controller —> Model.

А вообще, подгонять реальные решения под термины – так себе затея. В вебе и на сервере можно выделить свой MVC, и в браузере; при этом чем являются сервер и браузер друг для друга – оставим в качестве упражнения для пытливого читателя (сам я в дурку не хочу).

этот код называется presenter

А также supervising controller (т.е. сорта говна). В вебе других не бывает, потому что вьюха не может активно взаимодействовать с моделью, т.е. подобные уточнения не требуются.

подгонять реальные решения под термины – так себе затея

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

class CategoryController extends Controller {
  // example.com/category/index
  public function index() {
    //
  }
  // example.com/category/list
  public function list() {
    //
  }
} 

Так сделано в ASP.NET MVC.

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

• А у нас есть! Есть MVC!