Дизайн класса: создание объекта только для создания объектов из дочерних классов дурной формы?

Question

В настоящее время у меня есть система сообщений, которая записывает в две таблицы, sent и received, которые в основном имеют одинаковую схему.

Я написал класс с именем Message, который заполняет введенные пользователем данные перед созданием двух дочерних классов, которые используют общий метод в Message для установки остальных свойств и записи каждого в базу данных.Единственным существенным отличием является одно поле, которое представлено в дочернем классе с соответствующей переменной.Все остальные свойства являются частью Message.

Дело в том, что Message не имеет никакой цели, кроме как предоставить общие методы и свойства для созданных объектов и облегчить доступ к классу базы данных, который является его потомком.из.

Это считается плохой практикой?Является ли класс Message монолитным или я должен продвигать его дальше и включать дочерние классы ради одного поля?Будет ли лучший подход, чтобы отделить классы полностью и иметь один для отправленных и один для полученных таблиц?

Answer 1

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

Вы следовали принципу: СУХОЙ - не повторяйте себя.Конечно, если разница действительно очень мала, вы, вероятно, упростите свой дизайн, поместив все в один класс.

Answer 2

Итак, у вас есть класс под названием Message, который содержит общие функции, и дочерние классы (т. Е.)

class SentMessage extends Message {

, которые облегчают определенные задачи для «отправленного сообщения»?

, что имеет смысл.Это зависит только от того, сколько функциональности является отдельным.Если единственное отличие состоит в том, что SentMessage и ReceivedMessage помечены как «отправленные» или «полученные», то лучше было бы иметь функцию getMessageType () в своем классе Message.Но если в этом есть больше сложностей, то да, вы на правильном пути.