Vladislav

https://sourcemaking.com
https://github.com/PhpFriendsOfDdd/state-of-the-union

https://refactoring.guru/

в примере с кораблём и пространством можно использовать паттерн "фабрика".
Делаешь третий класс, в нём поле, которое содержит Space, и метод который будет принимать координаты нового корабля и возвращать созданный экземпляр. В этом методе и будет проверка.

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

В любом случае, в отрыве от конкретной задачи, вопрос смысла не имеет.

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

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

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

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

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

Графы и графовые алгоритмы являются хорошим краш-тестом для memory. Очень сложно придумать оптимальную структуру для графа чтоб было и экономно и быстро искать исходящие и входящие ребра в вершину.

Есть компактные структуры из примитивов такие как матрицы смежности например. Но они могут быть плохие
в другом. Например в поиске в глубину. Насколько Алгоритм Дейкстры пригож для этих структур - никто не знает.

Я-бы предложил брать большой граф на несколько тысяч вершин и гонять его в разных структурах добиваясь
хорошего соотношения скорости к размеру потребляемой памяти.

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

Я бы действительно не вводил сущность ребро. И просто в вершинах хранил список соседних вершин (оно еще называется список смежности). Так экономнее, быстрее и проще.

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

Если вы хотите построить хорошую архитектуру, то должны проектировать ПО исходя из best practice (классика по типу SOLID, DRY и т.д.) В данном случае мне не очень понятно за что отвечает класс Messager. Если это обобщенный класс одной беседы, то тогда логичным было бы хранить данные о собеседниках и сообщениях в объекте данного класса (если вы предполагаете наличие больше, чем одной беседы).
Также, если вы хотите усложнить приложение, то логичным выглядит создание классов-интерфейсов (для обмена сообщениями, т.е. отправкой, сохранением, работой с базой данных). Вот паттерны, которые могут быть полезны в случае задачи именно с кешированием базы данных (proxy, chain of responsibility).

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

Вариант сохранения данных в классе (вместо объекта класса) заставляет задать вопрос (особенно, если задачка учебная) о возможности создания двух объектов данного класса и целесообразности этого. В случае же, если объект данного класса будет лишь 1 (aka паттерн singleton), то нет необходимости хранить данные в классе, это будет даже вредно, поскольку без самого объекта эти данные не имеют смысла.
P.S. Я никакой не эксперт в архитектуре, это лишь мое видение и чуточка опыта.