Должен ли я использовать наследование, если я хочу уменьшить коды котельной плиты в этом сценарии?

Question

У меня есть класс Pojo, соответствующий таблице в базе данных. Класс Report.java имеет несколько полей:

class Report {
   public Date createDate;
   public String creator;
   public String description;
   public String id;
}

Из первого требования мне нужно вернуть объект Report, используя идентификатор для поиска его в базе данных. Ответ должен содержать только эти 4 поля. Но теперь они хотят иметь другую конечную точку REST, такую, чтобы с идентификатором мне нужно было возвращать дополнительную информацию в ответе, такую ​​как Date validUntil; Я думаю использовать наследование для этого, например:

class ExtendedReport extends Report {
  public Date validUntil;
}

Я не уверен, что это лучший способ уменьшить котельную плиту, или я должен сделать другой способ?

Спасибо.

Answer 1

Что я узнал с помощью «доменного дизайна»: не пытайтесь найти модель «silverbullet».Всегда есть разные способы представления вашей концепции.Модель всегда зависит от контекста.

Здесь, способ хранения report - это одно представление.Ваш REST-клиент хочет прочитать это другое представление.Вы можете представить себе представление для каждого варианта использования.

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

Кроме того,я бы избегал наследования, предпочитая какой-то интерфейс, если необходимо, принимая некоторую избыточность кода.

Answer 2

Обычно существует разделение объектов между различными слоями приложения, это означает, что вы можете иметь объект Report, который отображается непосредственно в вашу базу данных, и в то же время иметь другой набор объектов, которые используются для взаимодействия с клиентами, которые вы также можете иметь третий набор объектов, ваш бизнес-объект, который будет содержать логику, соответствующую вашему приложению. Обратите внимание, что вам нужно будет поддерживать логику, которая конвертирует между этими объектами, может быть, шаблон строителя или что-то подобное. В качестве небольшого примера рассмотрим ваш случай, вы можете иметь:

1. Отчет: класс с отображением 1 к 1 в БД, позволяет легко сохранять и извлекать объекты
2. ReportDAO: содержит те же поля, что и отчет, но с дополнительными функциями, которые приложение может использовать при манипулировании этими отчетами (сейчас ничего не могу придумать)
3. ReportDTO / ExtendedReportDTO: у вас может быть несколько классов с наследованием или без него, которые будут содержать только поля + методы получения / установки и используются для связи с клиентами.

Это может быть неочевидно при использовании этого простого примера, но разделение вашего объекта значительно упростит расширение и модификацию вашего приложения в дальнейшем. В настоящее время у вас может быть одна и та же информация на всех уровнях, но позже это может измениться, также неплохо бы не раскрывать свой бизнес-объект, поэтому, если вы используете класс Report в своем приложении, не стоит делиться это в API например. Поэтому я бы сказал, что здесь вы можете использовать наследование, но для меня, по крайней мере, я не считаю хорошей идеей иметь эти же объекты на уровне приложения и БД.

Answer 3

Если обе конечные точки REST должны возвращать один и тот же отчет , но предоставлять разное количество информации, тогда может оказаться полезным @JsonView.

Вот пример http://rsdn.org/forum/flame.politics/7430262

public class Views {
    public static class Public {
    }

    public static class Internal extends Public {
    }
}

public class Item {

    @JsonView(Views.Public.class)
    public int id;

    @JsonView(Views.Public.class)
    public String itemName;

    @JsonView(Views.Internal.class)
    public String ownerName;
}


@JsonView(Views.Public.class)
@RequestMapping("/items/{id}")
public Item getItemPublic(@PathVariable int id) {
    return ItemManager.getById(id);
}

@JsonView(Views.Internal.class)
@RequestMapping("/items/internal/{id}")
public Item getItemInternal(@PathVariable int id) {
    return ItemManager.getById(id);
}

Answer 4

Если класс отображает от 1 до 1 объекта базы данных, и вы используете отображение ORM , хорошо разделить два класса и использовать все преимущества наследования.

Как общийПодход, который я смиренно предлагаю разделить Модели (которые отображают репозиторий, например, реляционную базу данных) на Модель представления, которые являются объектами, возвращаемыми клиентам.