Demian Smith

Первый вариант предпочтительнее. Потому что первый вариант - это рецепт: всегда кидайте исключение когда функция не может вернуть (или сделать) то что от неё ждут.

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

Я так понял что вы еще не разобрались с тем как пользоваться системой контроля версий. Отсюда и желание положить несжатые файлы на сервак чтоб не потерять их. Так никто не делает, потому что это путь к провалу. Как делают:
1. Весь код хранится в системе контроля версий (GIT). Считайте что это файловое хранилище вашего проекта, к которому имеет доступ любой разработчик
2. Перед тем как залить код на сервер, он прогоняется через программу, которая жмёт и склеивает в один файл весь javascript и css. Обычно этот шаг автоматизирован. В вашем случае я бы начал делал эту рутину руками, пока не надоест и не захочется это автоматизировать при помощи, например, Gulp.

Вот тут вы можете зарегистрироваться и создать приватное GIT-хранилище для своего проекта: https://bitbucket.org/, а затем положить в него файлы проекта. После того как вы зарегистрируетесь, и создадите GIT-хранилище (кстати, в терминах гита, хранилище называется "репозиторий"), у вас появится ссылка на это хранилище. Эта ссылку - тот адрес, по которому хранятся рабочие файлы вашего проекта. Для других участников проекта (разработчики, заказчики, тестировщики) гит-репозиторий проекта важен даже больше, чем файлы на сервере. Потому что к файлам на сервере обычно имеют доступ только избранные, а к файлам проекта дожны иметь доступ все участники.

Во-первых, вы молодец, что движетесь в этом направлении. Продолжайте в том же духе.

По коду есть следующие замечания/предложения по улучшению:
- Делегирование подразумевает передачу некоторого функционала другому объекту. По сути, когда вы создали объект класса и выполнили метод этого объекта - вы уже делегировали некую функциональность. Например в контроллере задачу по выборке юзера вы делегировали объекту класса User. В случае же с классами User и Image, происходит внедрение класса Image в User (привет Dependency Injection), но дальше Image никак не используется классом User. Т.е. происходит Dependency Injection, но нет делегирования. На том этапе, который я сейчас вижу, я бы не стал внедрять Image в User. Сейчас это выглядет как задел на будущее, но любой опытный программист подтвердит, что композиция, созданная на будущее - ненужная композиция.
- Глядя на структуру классов, мне не совсем понятно чем они занимаются. Вроде как класс User и Image должны хранить информацию о пользователе и картинке (об этом нам говорит $id в конструкторе). Но в тех же классах есть логика по выборке данных из базы. По-хорошему выборкой должны заниматься другие классы. Лучше разделить задачи выборки и хранения на 2 разных класса. Я очень рекомендую вам ознакомиться с паттерном Data Mapper (наример тут designpatternsphp.readthedocs.io/en/latest/Structu... или тут codeinthehole.com/projects/domain-model-mapper-a-p... На мой взгляд, Data Mapper - это то что вам сейчас нужно реализовать чтоб получить чёткую структуру кода и разделение ответсвенности за выбор/хранени.

По поводу делегирования. Просто старайтесь чтоб ваши классы были как можно меньше. Критерий 1-3 метода на один класс вполне может подойти (помните, что это не золотое правило). Когда у вас появится желание добавить еще один метод в класс A - спросите себя, а нужен ли там вообще этот метод? Может лучше переложить всю ответственность на новый класс B, в который вы будете передавать объект A (или какое-то из его полей), а сам класс B уже проведёт необходимые преобразования/вычисления? Это и будет делегирование в том виде, в котором его ждёт от нас банда четырёх (если вы еще не читали их книгу, то это must read для любого программиста).

Фух, длинный ответ получился. Надеюсь, что не зря.