Цитата:
Сообщение от
dech
Да, согласен, надо контролировать, что уже есть в методе, чтобы не допустить ошибку Error::wrongUseOfFunction().
Поймать ошибку на уровне компиляции завсегда лучше чем в рантайм. Лично для меня это перекрывает все остальные удобства и недостатки.
Сама по себе логика методов initFrom* понятна. Например, в таблице A есть внешний ключ на таблицу B, и нам этого не достаточно а нужно ещё помимо ссылки сохранить (для истории/для производительности/для гибкости) текущие значения каких-то ещё полей из таблицы B. В таком случае реализуя на таблице A метод initFromB мы создаём некоторую абстракцию, мы позволяем таблице А самой решать какие поля забрать из таблицы B. Если в дальнейшем понадобится изменить состав таких полей, то это можно будет сделать не меняя внешний код.
Если у таблицы несколько внешних ключей, то получаем набор методов initFrom*. Но каждый из этих методов по логике должен вызываться строго в определённый момент, в момент инициализации соответствующего внешнего ключа. Мы же не рассматриваем ситуацию при которой на входе у нас кучка безликих курсоров, а на выходе мы должны получить целостную запись
Единственное теоретическое применение обобщённого метода InitFrom, которое приходит в голову - это выполнение каких-то одинаковых действий при инициализации разных полей. Но что это может быть?
Ваш паттерн явно и намеренно нарушает Принцип единственной ответственности (Single Responsibility Principle) - та самая S в известной аббревиатуре SOLID