Сам отвечу на свой вопрос. Подпись можно настроить, но только в стандартной версии джмейла, и соответственно работает эта настройка тоже только в стандартной версии.
Чтобы были в одной локальной сети, как несколько устройств, которые напрямую подключены к одному роутеру. Когда в одной сети обращаешься, к устройству по ИП адресу, то сразу и попадаешь на это устройство, а когда обращаешься через интернет, попадаешь куда то посередине.
PS3 - это Sony Playstation 3,
PSN - это Playstion Network - специальная сеть, но платная.
Если организовывать локальную сеть, то в принципе не имеет значения что за устройства.
Как то у тебя сложновато получилось... На пхпклабе доктрину рекомендовали, но она мне сложноватой показалась и требовательной к ресурсам, сам проверял. В доктрине понравилось, что знания о том как хранятся данные может хранить сама сущность, но там правда в виде аннотаций. На гитхабе понравилась такая реализация https://github.com/fordnox/mikron все предельно просто и понятно, но функционал сильно слабоват. А так ничего очень простого и относительно универсального там не нашел.
Спасибо, Максим. И все таки как датамаппер покупателя должен взаимодействовать с объектом заказа? ведь у покупателя он свой... И допустим что сущность покупателя, он же пользователь, может присутствовать и в других объектах, например в комментариях. Как вообще в подобных случаях взаимодействуют между собой сервисы-датамапперы-сущности, когда между сущностями появляются связи. Интересуют именно датамапперы.
1. Текучий интерфейс, улучшает только читаемость кода, но добавляет проблем с тестированием. Лучше не использовать без особой нужды.
2. Просто набор методов. Что-то передал в качестве аргумента - что-то получил на выходе. Наиболее универсальный способ.
3. Неизменяемый объект. Передаешь что-то при создании и дальше работаешь только с тем, что передал при создании.
А если задать вопрос с другой стороны (функционал). Какие классы конструировать для таких задач:
1. Загрузка данных авторизованного пользователя в посреднике, чтобы в основном коде иметь возможность получить какие-то свойства пользователя.
2. Загрузка данных просто какого-то пользователя для отображения их на странице.
3. Работа с профилем, может быть как собственный так и чужой: создание, обновление, удаление, получение, валидация и т.д.
Спасибо за ответы.
У меня нет конкретного примера или задачи, это именно абстрактный вопрос из любопытства, я хочу узнать, какой вариант применим в каких ситуациях или не применим или вообще так не принято делать. Я поправил примеры, сделал их еще абстрактнее.
Комментарии к примерам:
Все три примера делают одно и тоже, различия только в количестве методов и их сигнатурах.
doSomething - просто что-то делает с $id, но во всех примерах - одно и тоже.
1. Сеттер устанавливает внутренний указатель в $id и возвращает свой объект ($this), дальше метод что-то делает с внутренним указателем ($id)
2. Метод что-то делает с переданным аргументом $id
3. Конструктор устанавливает внутренний указатель в $id, дальше как в примере 1.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.