Ну как же, ORM принимает объект, а записывает в БД строки. И обратно - берет из БД строки, а отдаёт объект. Это то что и делает мой маппер. Но как быть со строками пришедшими из формы? Делать отдельный метод в маппере для их проверки и записи в БД? Или строить из них обьект, а потом записывать его в БД?
А что код? SessionRegistry extends Registry {} - с реализацией абстрактных методов родителя конечно.
Абстрактный у меня суперкласс Registry - работает как интерфейс, плюс базовый функционал, общий для всех наследников.
Я знаю, что такое позднее статическое связывание.
Когда я пишу у родителя в getInstance() static:$instance - я вызываю не свойство Registry, а свойство его наследника, у которого будет вызван метод getInstance(). Вот, например, что должно выполняться (по логике работы static) при вызове SessionRegistry::getInstance():
public static function getInstance(): Registry
{
if (!(SessionRegistry::$instance instanceof SessionRegistry)) {
SessionRegistry::$instance = new SessionRegistry();
}
return SessionRegistry::$instance;
}
Всё прекрасно - должен вернуться новый SessionRegistry (наследник Registry, возвращаемый тип в порядке).
При единичном вызове так и происходит, но при повторных вызовах разных наследников - начинается сумасшедший дом. :/
Спасибо, я примерно к такому же выводу по поводу конструкторов пришёл в последнее время. Насчёт методов - да, у меня первоначально всё было в ::init(), но я сейчас думаю - возможно, мне придётся менять последовательность и вставлять промежуточные процедуры между вызовами этих методов в клиентском коде.
Дмитрий Ковальский: хорошо, допустим, для периодически очищаемых логов временная переменная пойдёт.
Какие тогда будут варианты для остальных двух кейсов?