xfg

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

Советую для понимания посмотреть пример в англоязычной википедии и там же реализацию на Java. Суть в том, что у вас есть игра лабиринт. И есть два режима игры, обычный - когда игрок может перемещаться из комнаты только в смежную комнату и магический режим - когда игрок может перемещаться в любую комнату. Алгоритм самой игры для обоих режимов один и тот же, а вот бизнес-правила перемещения игрока по комнатам - разные. Вы реализуете эти бизнес-правила в OrdinaryRoom и MagicRoom, а в самом алгоритме игры вместо того, чтобы создавать какой-то из этих объектов - вызываете просто абстрактный метод makeRoom(). А затем создаете два подкласса, которые будут реализовывать метод makeRoom и возвращать нужный тип комнаты. Таким образом вы получаете два различных режима игры написав один алгоритм.

Вообще смысл данного шаблона довольно сложно понять. В интернете его почти всегда объясняют неверно. Прямо как пример на C#. Это совсем не то, о чем писали в книге банды четырех. Пример соответствующий тому о чем рассказывается в книге реализован в примере на Java. Нужно приложить усилия и постараться вникнуть в идею. Можно перед этим изучить Template method, его проще понять, там похожая идея, только там вы перекладываете часть поведения на подклассы, а здесь перекладываете создание объекта на подклассы. Factory method практически всегда используется в связке с Template method если мы говорим о классической реализации шаблона из книги банды четырех.

Вообще шаблон не настолько распространенный насколько может показаться. Мне с 2002 года в моей практике не пригодился ни разу.

Да, экшены так и делают. Сервер может отправлять около 20 снепшотов игрового состояния на клиент, то есть приблизительно каждые 50 миллисекунд. Чтобы изображение не дергалось отображение игрового состояния смешают назад в прошлое скажем на 50 миллисекунд, а клиент таким образом имеет возможность интерполировать перемещение игроков и анимации между текущим и предыдущим состоянием. Соответственно и сервер должен рассчитывать ввод пользователя в прошлом учитывая это смещение на 50 миллисекунд, учитывая время на путешествие пакета от клиента до сервера и возможно что-то еще, чтобы сделать стрельбу или маханием мечем максимально точным.

Для пошаговой игры это избыточно. Там достаточно просто отправлять новое состояние с сервера только в ответ на ввод пользователя.

Другой вопрос стоит ли для этого использовать websocket php, когда насколько мне известно unity итак предоставляет возможности для организации мультиплеера.

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

Вы также всегда имеете возможность посмотреть популярные open-source решения и убедиться какой точки зрения придерживается сообщество.

linux + docker + git вот и всё окружение.

Прочитать соответствующий RFC https://tools.ietf.org/html/rfc6455 чтобы понять, как происходит рукопожатие и какие байты в переданном сообщении за что отвечают. После этого будет понятно как написать реализацию. Я досконально уже не помню, но фактически от клиента приходит обычный http запрос с определенными заголовками, сервер разбирает этот запрос и если всё ок, то сохраняет открытое соединение в массив, если нет, то отправляет соответствующий ответ и закрывает соединение. Дальше по открытому соединению начинает сыпаться поток байтов от клиента их нужно разбирать, чтобы понять длину сообщения, сами данные переданные в фрейме, закончился фрейм или еще нет и тому подобное. Обратно также кодировать данные в поток байтов и отправлять по открытому соединению. Каждый байт в переданном фрейме несет определенный смысл. Обо всем этом подробно написано в RFC, но на английском. Вообще это хорошо примерно понимать как работает, но глупо писать такую низкоуровневую реализацию, когда есть готовые. Такие вещи развивают и поддерживают годами. Вы же не пишите HTTP серверы, а берете готовые вроде nginx и тому подобное.

В каком месте можно полученные данные подготовить к записи в бд.

Как сделать, что бы на стороне клиента, один websocket отвечал за сообщения, другой за статьи. (Или за эти два действия отвечает один websocket, тогда как мне на сервере это различать).

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

["id", "controller/action", {param1: value1, param2: value2}]

в ответ получать
["id", "OK"]
если запрос был обработан успешно или
["id", "ERR", {error: "action not found"}]
если произошла ошибка. По переданному id в массиве, можно понимать, к какому запросу относится ответ.
Для уведомлений (событий) сервер может отправлять клиентам что-то такое
["user_added", {user: {...}}]
и т.д. Этот протокол необходимо придумать самому или выбрать из готовых (популярных пока нет) и написать его реализацию (клиентскую и серверную часть) или опять же взять уже готовую.

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

Но это уже всё должно быть, просто возьми real-time фреймворк. Там за тебя написали и websocket сервер и протокол поверх него и экшены уже есть. Всё низкоуровневое уже готово. Бери и пиши приложение. В nodejs самый популярный это например https://github.com/socketio/socket.io, а в php я не знаю, но уверен, что тоже есть что-то популярное.

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

Без знаний архитектурных принципов делать рефакторинг бессмысленно. Это будет переливание из пустого в порожнее. Уже упомянули прочитать и добавить MVC если его нет. Для CRUD-приложения будет достаточно. Потом можно почитать про GRASP и SOLID. Потом про DDD, которое дает целостное представление об архитектуре. Всё в контексте объектно-ориентированной парадигмы. Для других парадигм ничего посоветовать не могу, не достаточно опыта.

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

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

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

Почему? Потому что ни какие тесты вам не дадут 100% гарантии, а вот устроить себе вечный ад из поддержки кучи хрупких тестов, которые десятками валятся от малейшего изменения - запросто. Выбираем золотую середину. Вариант выше, дает достаточную уверенность, что скорее всего всё работает как ожидается. Важный функционал тоже работает как ожидается.

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

Тестировать нужно только публичные методы класса. Вообще лучше внедрить внешние сервисы которые отвечают за сохранение и выгрузку в конструктор этого класса, замокать работу с базой/выгрузку и написать чистый юнит-тест. Такие тесты будут быстрыми, короткими и легко поддерживаемыми. На самый важный функционал сайта потом можно будет написать несколько медленных функциональных тестов. И всё, этого вполне достаточно. Сейчас же вы хотите интеграционный тест написать. Уродливый, медленный, с кучей лишнего бойлерплейта. В этом очень мало смысла. Нужно писать юнит-тесты на свой код и только для важных фич типа оплаты или регистрации писать функциональные тесты. Интеграционные тесты не писать вообще. Помните, каждая лишняя написанная вами строка кода, требует вашей дальнейшей поддержки в будущем. Пишем тесты, которые дают наибольший результат при минимуме кода.