Каков общий дизайн для класса с ORM для базы данных и многими не-базисными методами?

Question

Я новичок в разработке классов с помощью ORM и пытаюсь создать класс, который изначально представлял собой просто класс ORM, сопоставленный с базой данных, но теперь его необходимо расширить многими операциями / методами.

Сценарий

Предположим, у меня уже есть класс ORM "Телефон" с некоторыми полями, такими как "messages", "phone_records", "photos" и т. Д. Он просто использовался для вставки / запроса этой информации в / из базы данных.Но теперь мне нужно добавить некоторые операции, не связанные с базой данных, например Phone.call (), Phone.set_alarm (), Phone.take_picture () и т. Д.

Вопрос

Iможет придумать два варианта: 1) расширить существующий класс «Phone» новыми методами, или 2) определить новый класс «PhoneOper» для новых методов и сохранить класс «Phone», содержащий только поля в базе данных и только для операций базы данных.

Мне кажется, что # 1 связан с классом ORM со многими другими операциями.Но для # 2, я не знаю, как их лучше отобразить.(например, «PhoneOper» может легко найти «Phone» для вставки в базу данных, или результат запроса «Phone» может легко найти соответствующий «PhoneOper» для операций.

Спасибо за ваше руководство!

Answer 1

Сомнительная часть здесь имеет класс Phone, который отвечает за хранение данных, помимо того, что уже является Phone. Класс Phone должен заботиться о том, чтобы быть только Phone. Объект Phone имеет данные и методы. Вы можете расширить методы, как вы говорите, и вам, вероятно, нужно сохранить состояние (данные) Phone (s). Вам просто нужно запросить у Phone данные, чтобы иметь возможность доставить эти данные другому объекту, ответственному за сериализацию, для хранения их так, как вам нравится. Используя уже созданный ORM или некоторый класс интерфейса базы данных, вы пишете сами.

Для использования средств базы данных вы можете использовать API внешнего объекта или класса БД или ORM. Вы также можете сохранить некоторую ссылку на эту внешнюю сущность внутри Phone, чтобы иметь возможность ссылаться на ее методы из Phone. Или иногда вы наследуете от класса ORM, чтобы его методы были доступны.

Если этот последний случай не является требованием для использования ORM (похоже, что он есть), он делает Phone похожим на ORM, а это не так, и я бы предпочел просто использовать API БД, или уровень обслуживания базы данных из Phone.

Расширение Phone путем создания подклассов с другими или дополнительными функциями выглядит нормально для меня. Вы также можете обдумать определение дополнительных интерфейсов с функциями и заставить некоторые классы телефонов использовать / реализовывать их.