Сергей

Ну прежде всего понять, что есть две (точнее больше) парадигмы. ОО и процедурная.
Это типы мышления. Первая это разбивать систему на части, как на компоненты. И описывать связи между ними. Вторая - Описать структуру данных и функции на ними. И у них есть свои плюсы и минусы. (да. ООП это не волшебная пуля.)
Второе. Применения ООП эффективно к достаточно сложной системе. Сложная в смысле, что твой мозг определит там много частей и много связей между ними. Например вывести на экран приветствие это вряд ли сложное.
Третье. Понять , что дублирование это зло. Это не только копипаст, но делать дважды похожие классы компонентов с начала. Применять нужно наследование. В суперклассы переносить общее.
Четвертое. Система должна быть гибкой. Если приходят новые требования, нужно легко их реализовывать. И реализовывать локально. Т.е. по мере поступления изменений, мы находим места которые часто изменяются и стараемся вынести их в отдельные классы. В итоге получаем, при новом изменении, мы меняем только этот класс ничего более не цепляя.
Пятое. понять что между компонентами есть некий протокол взаимодействий. И для компонент важен именно он, а не реальный объект по ту сторону. Пример: розетка . не важно какая она в стене, в удлинителе, или от большой черной коробки, но в нее можно подключить утюг, компьютер, чайник и проч. Есть протокол - две дырки, напряжение 220 и достаточная мощь и этого достаточно. Это дает возможность менять компоненты не затрагивая остальные.
Примерно так.
По поводу принципов. любых. (ооп или солид) Обязательно нужно знать что они решают. Какую проблему. Это позволит не усердствовать. А применять в меру. оставляя код проще.
ну и книги по анализу.

навскидку (не разбираясь с логикой класса)
у тебя много методов зависят просто от $this->route
их уже можно выделить в один класс.
если есть аналогичные моменты от других переменных поступать также.
Вообщем разбиение делается так: анализ структуры класса и выделение подсттруктур переменных + методов. Эти подструктуры будут внутренне сильно связаны. И слабо связаны между собой. Это будет намек, что можно выделять классы из текста.
Пониманию структуры может помочь анализ ответственности год-класса.
Как бы первое, что нужно сделать. Остальное станет ясным по мере разбиения.

Дело не в том какая парадигма лучше/хуже. Дело в том какая ближе к вашему мышлению и моделировании области которую вы описываете. Если вы мыслите процедурами, то ооп в коде будет притянута за уши. Если код понятен, легко читается, то этого достаточно.
В качестве развития можно почитать что-то из оо проектирования.
Процедурность и ООП это два разных подхода к пониманию системы. (Это не ключевые слова в синтаксисе. ). Разные подходы к решениям проблем всегда полезны. Хотя не напрямую.
Т.е. умейте много, применяйте что эффективно для конкретного случая.

Вообще, это правильный подход к диаграммам. )
Вот что писал Боб Мартин:
"Возьмите за правило выбрасывать ненужные UML-диаграммы. А еще
лучше, не создавайте их на постоянном носителе. Рисуйте на доске или
на клочках бумаги. Почаще стирайте с доски и выбрасывайте эти об-
рывки. Не привыкайте к инструментарию CASE или к графическим ре-
дакторам. Для таких инструментов есть свое время и место, но жизнь
большинства UML-диаграмм недолговечна."
Хотя, далее, некоторые полезно и сохранять. Общий дизайн системы (идея) или те моменты которые из текста программы будет сложно понять.

Упрощенно можно так подходить к выделению классов и интерфейсов.
Есть два реальных объекта. Они относятся к разным классам. Со своими особенностями. Но у них есть некие одинаковые свойства. Например шаблоны функций. пример в общем случае быстрая сортировка это шаблон реализующий алгоритм, но этот шаблон не знает как реально сравнивать объекты. То есть это абстрактный класс объединяющий конкретные быстрые сортировки конкретных объектов. Можно сказать, что абстрактный класс это вынос общих методов и полей их своих потомков. При том что реально мы никогда не создадим экземпляр этого класса.
Выделение интерфейса. Обычно применяется для разделения систем на отдельные на зависимые части. Например кнопка включает лампу. В программе это реализуется так
кнопка имеет поле лампа. т.е. реализация кнопки зависит от лампы. Если тип (или код) лампы поменялся, то и часть кода ответственная за кнопку тоже меняется. По крайней мере должна протестироваться. Но можно договориться разделить все устройства которые могут что-то включать (кнопки) и могут быть включены (лампы, двигатели, телевизоры...) и указать как им взаимодействовать.
Т.е. примерно так:
Кнопка управляет устройствами.
Устройство должно иметь метод "включить".
Лампы, телевизоры, двигатели должны реализовать это метод у себя.
Итого одна и та же кнопка (без изменения кода) управляет целой группой разнородный устройств (но реализующих общие правила взаимодействия)

По картинкам:
у нас есть объекты
связь 0, связь 1, ...связь 3
так же объект шина из связей.
общее для них это они все имеют имя.
также они имеют некоторые правила передачи сигналов.
Это дает нам два класса Net и Bus. Кроме того Bus включает в себя много Net.
Далее хотелось бы , что бы эти классы были независимы от правил. т.е что бы правила мы могли назначать сами. возможно динамически. Поэтому net и bus имеют метод назначающий правила rule (с общим интерфейсом) (которые можно менять, и не менять реализацию net, bus ).
Итого Выделили общие свойства из net, bus в абстрактный класс AbstractNet. bus включает много net. Вынесли правила (которые будут часто меняться и которые мы возможно еще не знаем) за общий интерфейс.
примерно так. упрощенно.