Entity (сущности) — зачем они нужны?

#java #ооп #java_ee #entity

Всем добрый вечер.

В ходе одного обучающего проекта наткнулся на необходимость использовать Entity (сущность).
В данном случае, существует 3 класса, наследуемые друг от друга:

Entity.java:

public class BaseEntity {
    protected Integer id;

    public BaseEntity() {
    }

    protected BaseEntity(Integer id) {
        this.id = id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public Integer getId() {
        return id;
    }

    public boolean isNew() {
        return (this.id == null);
    }

    @Override
    public String toString() {
        return String.format("Entity %s (%s)", getClass().getName(), getId());
    }
}


От него наследуется NamedEntity:

public class NamedEntity extends BaseEntity {

    protected String name;

    public NamedEntity() {
    }

    protected NamedEntity(Integer id, String name) {
        super(id);
        this.name = name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    @Override
    public String toString() {
        return String.format("Entity %s (%s, '%s')", getClass().getName(), id, name);
    }
}


А от него — User:

import java.util.Date;
import java.util.EnumSet;
import java.util.Set;

import static MealsUtil.DEFAULT_CALORIES_PER_DAY;

public class User extends NamedEntity {

    private String email;

    private String password;

    private boolean enabled = true;

    private Date registered = new Date();

    private Set roles;

    private int caloriesPerDay = DEFAULT_CALORIES_PER_DAY;

    public User() {
    }

    public User(Integer id, String name, String email, String password, Role role,
Role... roles) {
        this(id, name, email, password, DEFAULT_CALORIES_PER_DAY, true, EnumSet.of(role,
roles));
    }

    public User(Integer id, String name, String email, String password, int caloriesPerDay,
boolean enabled, Set roles) {
        super(id, name);
        this.email = email;
        this.password = password;
        this.caloriesPerDay = caloriesPerDay;
        this.enabled = enabled;
        this.roles = roles;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public Date getRegistered() {
        return registered;
    }

    public void setRegistered(Date registered) {
        this.registered = registered;
    }

    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
    }

    public int getCaloriesPerDay() {
        return caloriesPerDay;
    }

    public void setCaloriesPerDay(int caloriesPerDay) {
        this.caloriesPerDay = caloriesPerDay;
    }

    public boolean isEnabled() {
        return enabled;
    }

    public Set getRoles() {
        return roles;
    }

    public String getPassword() {
        return password;
    }

    @Override
    public String toString() {
        return "User (" +
                "id=" + id +
                ", email=" + email +
                ", name=" + name +
                ", enabled=" + enabled +
                ", roles=" + roles +
                ", caloriesPerDay=" + caloriesPerDay +
                ')';
    }
}


Я не совсем понимаю смысл такой "матрёшки". Внятного объяснения на русском не обнаружил.
Прошу поделиться смыслом сущностей, особенно меня интересует, почему мы пишем отдельно
id, отдельно name, отдельно всё остальное. Объяснение нужно прямо для чайников, а именно,
почему мы не можем без них обойтись или почему лучше их использовать. Также, подойдут
русскоязычные ресурсы, на которых разжёвывают, почему мы должны пользоваться сущностями
и вообще для чего они.
    

Ответы

Ответ 1

Решить каким образом использовать сущности и использовать ли их вообще поможет понимание
следующей модели представления даннных.

Когда мы говорим о сущностях в абстрактном смысле мы всегда в том или ином виде подразумеваем
использование какой-либо модели данных. В частности, в программировании применяется
EER-модель (Enhanced Entity-Relationship model). Расширенная модель включает все концепции
ER-модели (entity-relationship model) и дополнительно включает понятия подкласса, суперкласса
и относящиеся к ним понятия специализации, обобщения и категоризации. Далее рассмотрим
базовую ER-модель.


  "Набор данных, обычно относящихся к какой-либо предметной области или
  тематической области, и структурированных таким образом, чтобы
  обеспечить установление отношений между отдельными элементами данных в
  соответствии с различными потребностями пользователей." G. Knott & N. Waites, Computing
3rd edition


ER-модель, модель «сущность — связь»

Модель была предложена в в 70-х годах Питером Пин-Шэн Ченом (сайт, статья).
Модель "сущность-связь" основывается на некой важной семантической информации о реальном
мире и предназначена для логического представления данных. Она определяет значения
данных в контексте их взаимосвязи с другими данными. Важным для нас является тот факт,
что из модели "сущность-связь" могут быть порождены все существующие модели данных
(иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.

Сущность фактически представляет из себя множество атрибутов, которые описывают свойства
всех членов данного набора сущностей. Например, как у вас в коде. Есть базовая сущность
BaseEntity, именованная сущность NamedEntity и конкретная User(пользователь). Таким
образом сущность - это объект, который может быть идентифицирован неким способом, отличающим
его от других объектов. 

Преимущества использования ER-модели


Высокая гибкость. Обеспечивают: модульность, что позволяет переиспользовать код следуя
принципу DRY; простоту рефакторинга
Местная автономия. В каждой отдельной части программы можно работать только с нужными
нам сущностями. 
Простота понимания. За счет семантического моделирования данных, при котором отдельная
сущность опирается на смысл этих данных. Любую модель легко изобразить в виде диаграммы.
Наличие и простота визуализации. Нотация П. Чена, Crow’s Foot, UML, DFD, IDEF0 и
IDEF1x, нотация Мартина, нотация Бахмана и др.


Недостатки использования ER-модели


Сложность. Модель предназначена для высокого уровня абстракции. Увеличивается объем
и сложность кодирования. Вам пришлось создать 3 класса со своими полями и методами,
хотя можно было бы их оформить в одном классе. Кроме того разработчикам  достаточно
сложно хранить всю иерархию классов в голове.
Безопасность. Трудно контролировать уровни доступности атрибутов сущности.
Трудно поддерживать целостность. Такая модель чувствительна к изменению атрбутов.